You meant to post the list too? It didn't reach the list. The problem with native libraries are:
1) Security If an EJB is allowed to load native libraries, then an EJB has no constraints on what it may do other than those imposed by the OS(which also may contain loopholes). Consequences: Unless you coded each EJB and own the server, there's a great degree of FUD about using EJBs in the first place. Also Pure Java servers become less robust than their counterparts. The ability to have binary reusable components is lessened. 2) Threading An EJB making a JNI call may spawn a number of native threads, some which may be running in a different process. I've integrated Java and native code as COM components (Win32) and OpenGL(Win32/Linux). COM is tricky, it has apartment rules that if not followed have very negative consequences and object/memory instantiation/disposal(for Object containment extra-apartment) rules that also yield ugly results if not followed. Thread juggling is often involved. Again this goes back to 1, security problems. As Sven points out, the Container runs within a Server, and even then, the server may be embedded into another application. An EJB or its helper classes(those in the same .jar) shouldn't load a native library. The container may choose to do so. The Server may choose to do so. The App in which the server is embedded may choose to do so. JDBC and JCA implementations may choose to do so. JMX may choose to do so. And so forth. Once the library is loaded it is available to whomever has access and permits over those classes with native methods. And an EJB may call them, directly or indirectly. My 2c, 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 > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]] On Behalf Of John Harby > Sent: Tuesday, October 01, 2002 11:54 AM > To: [EMAIL PROTECTED] > Subject: Re: Does the spec allow JNI in EJB? > > > 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". > ==========================================================================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".
