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