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