> From: Craig R. McClanahan
> Sent: Friday, July 20, 2001 7:44 PM
...
> > Yes, I use it in webapp context also.  Let's explore 2 scenarios
> > starting with the following:
> > 
> >     . my code (in webapp context) creates a Digester
> >     . add rule-A to digester
> >     . call digester.parse()
> > 
> > Senario 1: digester.setUseContextClassLoader(false)
> >     . digester fires rule-A which needs class 'my.code.Run'
> >     . uses Class.forName() which uses ClassLoader of Digester
> >       Digester is defined in webapp-ClassLoader, so that's
> >       the one that's used
> >     . webapp-ClassLoader delegates to bootClassLoader, which
> >       fails to find it
> >     . the webapp-Classloader looks for and finds the class
> > 
> > Senario 2: digester.setUseContextClassLoader(true)
> >     . digester fires rule-A which needs class 'a.b.stuff'    
> >     . uses the Context ClassLoader.  This classloader is rooted
> >       in the servlet-container and is quite likely the
> >       bootClassLoader.
> 
> This is not actually correct.  In most current servlet containers, the
> context class loader is set to the webapp class loader for the request
> currently being processed by this thread.  This behavior will 
> be mandated
> in J2EE 1.3.

Like I said in my original message, I'm not an expert on ClassLoaders
in Servlet containers.  I read through what you wrote, and I think I'm
missing something.  For the sake of clarity, let me just share the results
I got, that led me to the statements I made.  In my class Digest.java
which is loaded by the web-app ClassLoader, I have the following method:

        private void parseIt(Digester digester, InputStream input)
                throws SAXException, IOException {

                ClassLoader ccl =
Thread.currentThread().getContextClassLoader();
                String clName = this.getClass().getClassLoader().getName();
                System.out.println("CL:  " + clName);
                System.out.println("CCL: " + ccl);

                digester.parse(input);
        }


And these are the results that I get (using Tomcat 3.2.2)

     CL:  org.apache.tomcat.loader.AdaptiveClassLoader12
     CCL: sun.misc.Launcher$AppClassLoader@71732b

My assumptions are that the "AdaptiveClassLoader12" is the context CL
provided by Tomcat, and "AppClassLoader" is the CL provided by the
JVM at startup.  If I'm interpreting this right, then my machine
shows that web-app CL is not "accessible" from
Thread.getContextClassLoader().

Do these results look correct, or am I interpreting them incorrectly?
Or perhaps I am misunderstanding the relationship between a
(thread) Context ClassLoader and a web-app (context) ClassLoader?

Thanks,
Gidado

Reply via email to