Zerbe John W wrote: > > 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".
It doesn't say "native library" but rather "loading a native library". Are you saying that "JNI" is the same as "loading a native library"? Since it would have been easy for the spec to disallow JNI by specifically saying "JNI" it would seem to me that someone thought that there was a difference. > > 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. > I don't understand that position. Unless the newer version disallows JNI then it would have no other impact. > Example: One of the details of JNI is that you must load the JNI class from a > non-reloadable class loader. I am not quite sure that I follow that. Due to the way that JNI is resolved only one JNI method source is allowed. Normally one could have two different implimentations of the "same" class if the classes were loaded with different class loaders. That is not possible with JNI because there can only be one JNI method - the class loader is not used to resolve it. That is an argument that no one has presented before but I believe it still falls into the category of reasons why one should try to avoid JNI in an EJB, rather than an absolute reason for why it should never be used. (I know I have had JNI classes which did not change for years so bouncing the server to update them every two years would have been acceptable.) > 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. Interesting. Since I know that the same class can be loaded via two class loaders and talk to the same JNI method I am curious why in the case you cite it was unable to use the JNI method. If true then it would break hot deploy which would be a non-trivial issue. > > 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". > Stop a thread? As far as I know there is no way to do that safely in java. And I can't find anything in the EJB spec nor in the J2EE spec that says it will try to stop a thread. Nor for that matter to even interrupt it. Could you provide a reference? =========================================================================== 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".
