On Mon, 17 Sep 2001, Jochen Schneider wrote:
> Date: Mon, 17 Sep 2001 17:08:21 +0200
> From: Jochen Schneider <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: Thanks for the note on JNI and class loading in the release
> notes
>
> Simon,
>
> unfortunately I am not too familar with the classloaders in Tomcat 3.2 and
> 3.3. If there are separate classloaders for each web app then you have the
> same situation as with tomcat 4.0 (Catalina).
>
The details of where you put the shared classes (so they don't get
reloaded) are different per Tomcat version, but the issue being raised
here is common to all of them.
One guarantee you have in servlet 2.3 containers (such as Tomcat 4) is
that the web application's class loader is accessible to a class loaded
from the shared repository. Thus, a shared library component can indeed
load a web app's class, if it does something like this:
ClassLoader cl =
Thread.currentThread().getContextClassLoader();
Class applicationClass =
cl.loadClass("com.mycompany.mypackage.MyClass");
A couple of notes about this:
* Although this support is commonly implemented in servlet 2.2 containers
(including Tomcat 3.2 if you use the Jdk12Interceptor), it's not
guaranteed to be portable there.
* For servlet 2.3 containers, it's required by the J2EE platform spec,
and therefore must be supported by the servlet container.
* This will work only when the library class is called in the context
of processing a servlet request -- for example, you will not be able
to do this in a static initializer or something like that.
* There is only one copy of the shared library class being accessed by
all of the web apps, so you have to program your library class in a
thread-safe manner just like you do with servlets.
> Regards Jochen
>
Craig
> ----- Original Message -----
> From: "simon colston" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, September 17, 2001 12:39 PM
> Subject: Re: Thanks for the note on JNI and class loading in the release
> notes
>
>
> > 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]
> >
>
>
