Here's my 2 cents: In my opinion, "native library" does equal JNI. The only way to call a native library from java code is via "Java Native Interface".
I am sure that you are aware of most of the dangers of calling native libraries from any mult-threaded java program. I believe that another reason the spec is written that way is to help you write EJB's that are not only portable across platforms, but are also portable across new releases of a given container. Example: One of the details of JNI is that you must load the JNI class from a non-reloadable class loader. We had an application that was using JNI from a helper class that was loaded via the reloadable servlet class loader. These people didn't understand why their app worked just fine until someone dropped in a new servlet class, the whole class loader was dropped, then the jni class was loaded again, and couldn't talk to the native library anymore. The same could potentially happen with an ejb container. The container may implement a "hot deploy" where you can drop in a replacement ejb jar file with all the same method signatures as the previous one, the current classes loaded by the container's class loader get dumped, and the class loading starts all over again, breaking your jni wrapper. I believe that containers typically make you "predefine" all jdbc drivers, JCA "connectors", etc so that the container can treat these thing specially. IE put them in a "system" classpath so that the only way to "reload" the class is via jvm recycle. Another reason you don't want to call native libraries that the container doesn't know about is the fact that an EJB can be configured to have a specific transaction timer. ie if a call to an ejb doesn't return within the configured transaction timeout time, the container needs to be able to attempt to "roll back" any updates that the ejb has done to this point, and stop the thread that the container assigned to the ejb call. If the jni code is in a "container managed" resource, those resources typically have to implement a method for the container to tell them to clean up anything associated with a given "transaction". These are just a couple of reasons that I believe the spec is trying to protect us from ourselves! :) -----Original Message----- From: Joe Schell [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 11:20 AM To: [EMAIL PROTECTED] Subject: Re: Does the spec allow JNI in EJB? Kevin Gaasch wrote: > > By posting your question to this list, we are assuming that you are > interesting in our interpretation of the specification. It is obvious > that you can read the language of the specification as well as any of > us. So, the only added information that we can provide to you is how we > believe the specification should be interpreted. So far, here is what I > have gathered from YOUR postings to this list: > > 1. You have already examined the specification and formulated your own > 'by the letter' interpretation (which is great, that's what it is for). > 2. Any postings that provide a 'beyond the letter' interpretation, you > reject because you are not interested in anything outside the scope of > the black-n-white text. No. My posting was intended to gather opinions as to whether "native library" equals "JNI". Or even to gather information from some other standard that either made it clear that JNI was allowed or that JNI was not allowed. > 3. The only posting that seems to be acceptable is "Yes, you have read > the specification correctly. JNI is not disallowed." > Nope. If you have a source, either another standard or something similar which says that "native library" equals "JNI" then feel free to post. However, no one posted anything like that. And, from the posts I saw, the vast majority seemed to take the stance that it was ok but it "just wasn't a good idea." Which I don't disagree with. There are dangers. But there is a great deal of difference between that and the stance that it should never ever be done that way. Of course if someone is going to make a statement that it should never be done that way then I would expect them to back it up with some reasonable explaination. Either from a source or a generalization from their own experience. There were some responses like that but they were either focusing on because there might be a better way or because it isn't "portable." The latter is redundant since JNI by its nature is not portable. And the former doesn't address the main issue in clear terms. And I am not saying that neither argument is without merit, but rather that neither clearly leads to disallowing JNI in an EJB. > Therefore, any more posting on this thread will add no value to your > original question. Now, if anyone is interested in discussing the > 'hidden meaning' of the specification with regard to JNI from EJB, then > please continue the discussion. Otherwise, could we please close this > thread. > > Kevin E. Gaasch =========================================================================== 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". DISCLAIMER: The information contained in this e-mail may be confidential and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorized. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator. ==========================================================================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".
