Barberstown, Straffan, Co. Kildare, Ireland.
Tel: +353-1-6012050 Fax: +353-1-6012051
Mobile: +353-86-2157900
www.codefoundry.com
-----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.
