My interpretation of this was that since the spec states that the functionality of loading a native library is reserved for the container then loading of libraries by EJBs or any helper classes running within that VM used by the container was forbidden by the spec. I realize that most vendors will allow this anyway but it would be interesting to hear what the folks on the spec JSR have to say.
>From: Juan Pablo Lorandi <[EMAIL PROTECTED]> >Reply-To: Juan Pablo Lorandi <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Does the spec allow JNI in EJB? >Date: Tue, 1 Oct 2002 04:57:11 +0100 > > > > > > > Taken from the "Enterprise JavaBeans TM Specification, Version 2.1" > > > > In section 25.1.2 it has the following. > > > > -------------------------------------------- > > � The enterprise bean must not attempt to load a native library. > > > > This function is reserved for the EJB Container. Allowing the > > enterprise bean to load native code would create a security hole. > > -------------------------------------------- > > > > This is my take on this. > > > > 1. An EJB must not load a native library. > > > > 2. An EJB Container can load a native library. > >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. > >That said, my Oracle JDBC OCI drivers are allowed to execute native >code. If you plan on looking for a way to plug-in that is somewhat >portable(the way of plugging-in, not the native code) start with JDBC. >It's quite possible that some Pure Java containers do not allow JNI at >all. > > > > > 3. Code in a JVM which is not part of the Container and is > > not referenced by an EJB can load a native library. > >Again this is MAY. Depends on the container. See point two. But for JDBC >this is a must. > > > > > 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. > > > > > The last point is the specific point of my question. > > > > My opinion is that, from reading the spec, that it > > specifically allows for the use of JNI in an EJB or at least > > does not dis-allow it. > > > >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. > >The reasons behind the spec not encouraging the usage of JNI are (among >others you certainly heard of) JDBC drivers that use native code & EJB >Servers/Containers that are/were CORBA servers. It's more of an >strategic/commercial choice. > >My 2c, > >JP > >==========================================================================To >unsubscribe, send email to [EMAIL PROTECTED] and include in the body >of the message "signoff EJB-INTEREST". For general help, send email to >[EMAIL PROTECTED] and include in the body of the message "help". _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
