Re: Does the spec allow JNI in EJB?

[Juan Pablo Lorandi]

Title: Message

-----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.
[JPL>] If the Container is in its exclusive VM, then it MAY prevent loading(The Server provides JDBC and JCA and runs them in a different VM). If it runs within a Server, then it MAY prohibit the loading of native libraries within itself. The server then will load JCA connectors, JDBC drivers, etc. and provide those to the Container. Unless the Container is responsible for instatiating, mananging and providing services to EJBs (in contrast with just exposing/indirect them), then it's a different story. Also, if you flatten Server and Container into one homogeneous block running inside a single JVM, then library loading may be allowed/denied depending on the context (see SecurityManager.getSecurityContext() , SecurityManager.getThreadGroup() ).

 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.
> >
> > 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.

> 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.