Re: Does the spec allow JNI in EJB?

[Sven E. van �t Veer]

I keep forgetting I have to do a 'reply all'


> Please also post to the list, not just me. The rest inline
>  
>  
> Juan Pablo Lorandi
> Chief Software Architect
> Code Foundry Ltd.
> [EMAIL PROTECTED]
>
> Barberstown, Straffan, Co. Kildare, Ireland.
> Tel: +353-1-6012050  Fax: +353-1-6012051
> Mobile: +353-86-2157900
> www.codefoundry.com
>  
> Disclaimer:
>  
> Opinions expressed are entirely personal and bear no relevance to
> opinions held by my employer.
> Code Foundry Ltd.'s opinion is that I should get back to work.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 01, 2002 12:27 PM
> To: Juan Pablo Lorandi
> Subject: Re: Does the spec allow JNI in EJB?

> I cannot agree with you.
>
>
> > Perhaps we could rephrase into(to match the spec): A container MAY load
> > a native library. A container MAY choose, running on an exclusive JVM
> > and implementing it's own SecurityManager, effectively prohibit the
> > loading of native libraries. So at least this feature is
> > Container/Server dependant. See the section Java 2 APIs Requirements
> > (it's 24.2.1 in ejb2.0, maybe it is 25.2.1 in ejb2.1) Table 19. It is
> > merely *recommended* that Containers deny such priviledges.
> >
> It is not the Container but the App server that MAY load Native
> Libraries. It MAY NOT however prohibit the loading of native
> libraries, as of the J2EE spec. JCA is an architecture defined to do
> just that. Using JCA these resources can and should be managed by
> the App Server and provide these to the Container.
> [JPL>] Well, the boundary of Container and Server is quite unclear
> to me. It's the container's responsibility to make JDBC APIs
> available. That means setting up DataSources too? It's not clear to
> me. Maybe you can add up to this providing quotes to the specs?
> > >
> > > 4. An EJB can call a JNI method.
> >
> > Yes, it may, but I wouldn't choose to do it directly. A simple wrapper
> > will suffice to keep you on the safe side of things without
> > relinquishing JNI.
>
> I think using a wrapper you�re just kidding yourself. A helper class
> runs inside the container. It�s just a workaround around the spec.
> [JPL>] A wrapper may keep threading management away from the EJB.
> You justify this in the paragraph below. I honestly don't care where
> this wrapper executes, as long as it encapsulates the JNI call. Not
> all wrappers are helper classes nor they must be colocated with the
> EJB. Oracle's OCI driver for java is a wrapper to the native driver.
> Same for DB2's drivers. They execute in the Server, if you
> wish(outside of the container) and they don't expose the threading
> issues to its clients.
>
> > In many scenarios JNI is harmless and transparent to the Java App; in
> > others it isn't(especially when threading is involved. A container
> > allowing code to load native libraries relinquishes control over the
> > resources it's supposed to manage, thus, It. Getting back to your
> > question, no, it's not forcefully disallowed. It is what you want it to
> > be: since it's not disallowed, you may assume it is allowed. Since it's
> > not explicitly allowed nor encouraged, you may want to steer clear from
> > it. Your choice.
>
> Exactly for the reasons you mentioned above it is disallowed in the
> spec, and therefore may not be portable to any app server. The safe
> way to do this, which may IMHO even use threading, is using JCA
> which to the container is similar to JDBC and may use JNI (that�s
> what it was made for) and bring this native library inside the
> transactinal scope of the container and make it possible for the
> container to manage the resources.
>  
> [JPL>] Presicely my point above. I wouldn't code an EJB that
> directly calls JNI. If an EJB is directly disallowed to create
> threads, I assume it won't be able to associate external threads
> with the VM either. That's why I advocate for some middleman that
> may spawn threads/associate threads with the VM and still be
> transparent to its clients. JDBC and JCA fit that
> purpose(transparent middleman) best and even provide extra features.