Jochen, Jonathon, Craig,
Would the same thing be true for Tomcat 3.2 and 3.3??
On Mon, 17 Sep 2001 10:06:18 +0200
"Jochen Schneider" <[EMAIL PROTECTED]> wrote:
JS> Hi Jonathan,
JS>
JS> we had the same problem and fixed it in the way described now in the Tomcat
JS> documentation.
JS>
JS> Probably one additional remark should be added to the documentation :
JS>
JS> If you place the Java code loading the native library outside of the web
JS> application (for example in $CATALINA_HOME/common/lib) it is loaded only
JS> once and the problem is solved.
JS>
JS> This sollution has some implication : The classes containing the native code
JS> are loaded by a classloader which has no knowledge about any class which
JS> resides in \Web-inf\lib. You will get an exception if you try to instanciate
JS> a class which resides in the \Web-inf\lib directory from your native code!
JS> You will also get an exception if you try to import a class which resides in
JS> the \Web-inf\lib\ directory from your java code in $CATALINA_HOME/common/lib
JS> since the two classes are loaded by different classloaders.
JS>
JS> This will not work (ClassA in $CATALINA_HOME/common/lib ansd ClassB in
JS> \Web-inf\lib\ ) :
JS>
JS> ClassA :
JS>
JS> import ClassB;
JS> public native static void doSomething(ClassB obj);
JS>
JS>
JS> ClassB :
JS>
JS> import ClassA
JS> public static void main(String[] args) {
JS> ClassA.doSomething(this);
JS> }
JS>
JS>
JS> Now it works again :
JS>
JS> ClassA :
JS>
JS>
JS> public native static void doSomething(Object obj);
JS>
JS>
JS> ClassB :
JS>
JS> import ClassA
JS> public static void main(String[] args) {
JS> ClassA.doSomething((Object)this);
JS> }
JS>
JS>
JS> Is this description correct? How do you handle this problem? Is there a more
JS> elegant sollution ?
JS>
JS> Regards,
JS> Jochen
JS>
JS>
JS>
JS>
JS>
JS> -------------------------------------
JS> Tomcat 4.0 and JNI Based Applications:
JS> -------------------------------------
JS>
JS> Applications that require native libraries must ensure that the libraries
JS> have
JS> been loaded prior to use. Typically, this is done with a call like:
JS>
JS> static {
JS> System.loadLibrary("path-to-library-file");
JS> }
JS>
JS> in some class. However, the application must also ensure that the library
JS> is
JS> not loaded more than once. If the above code were placed in a class inside
JS> the web application (i.e. under /WEB-INF/classes or /WEB-INF/lib), and the
JS> application were reloaded, the loadLibrary() call would be attempted a
JS> second
JS> time.
JS>
JS> To avoid this problem, place classes that load native libraries outside of
JS> the
JS> web application, and ensure that the loadLibrary() call is executed only
JS> once
JS> during the lifetime of a particular JVM.
JS>
JS>
JS>
JS> ----- Original Message -----
JS> From: "Jonathan Eric Miller" <[EMAIL PROTECTED]>
JS> To: "Tomcat Developer List" <[EMAIL PROTECTED]>
JS> Sent: Saturday, September 15, 2001 5:59 AM
JS> Subject: Thanks for the note on JNI and class loading in the release notes
JS>
JS>
JS> > I'm guessing that Craig is the one that added the section about JNI and
JS> > class loading in the RC1 release notes. I just wanted to say that I
JS> > appreciate that you documented this.
JS> >
JS> > I also noticed that you fixed a problem that I noticed with the Base64
JS> > encoder where it had trailing zeroes.
JS> >
JS> > Thanks, Jon
JS> >
JS> >
JS>
JS>
JS>
JS>
JS>
--
simon colston
[EMAIL PROTECTED]
