tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Herrmann, Sascha \(GE Healthcare\)" <>
Subject RE: WebappClassLoader - don't understand what's happening
Date Thu, 02 Jun 2005 11:49:32 GMT
Thanks for your reply.

It could be. How is a class "pushed" to a shared library?

I used the following code:

      System.out.println( "BoneDBTransactionImpl2  LOADING ***************************************"
      System.out.println( "Thread Classloader is: " + Thread.currentThread().getContextClassLoader()
      System.out.println( "Hash: " + Thread.currentThread().getContextClassLoader().hashCode()
      System.out.println( "Class: " + Thread.currentThread().getContextClassLoader().getClass().getName()
      System.out.println( "---------------------------     " );    
      System.out.println( "Class Classloader is: " + BoneDBTransactionImpl2.class.getClassLoader()
      System.out.println( "Hash: " + BoneDBTransactionImpl2.class.getClassLoader().hashCode()
      System.out.println( "Class: " + BoneDBTransactionImpl2.class.getClassLoader().getClass().getName()
      System.out.println( "BoneDBTransactionImpl2  LOADING ***************************************"

I put this into a static initializer block of a class that is in a jar in both WEB_INF\lib
I also added this code the constructor of that class. And to make sure to see what loader
belongs to what app I also added the 
code to some methods of classes that are either in app A or in app B and not in both.

I start app A. The output shows that

- the class is loaded in app A by WebappClassLoader with hash A
- the instance is created in app A using the Class loaded by WebappClassLoader with hash A.
- Thread context classloader is WebappClassLoader with hash A.

Then I start app B. The output shows that

- the instance is created in app B using the Class loaded by WebappClassLoader with hash A
- Thread context classloader is WebappClassLoader with hash B.

The class exists in jar files in both WEB-INF\lib directories, but not in any other lib directory.
And - if the class was loaded by a shared classloader, shouldn't the xxx.class.getClassLoader()
return the StandardClassLoader?

I must admit that I am not too familiar with the deeper concept of J2EE classloading apart
from the information found on some web pages.

So, if the class indeed is loaded by WebappClassLoader A, how can it be "pushed" to become
a shared one?
And how can I prevent this from happening?
Or am I making a mistake reading the output? I am sure that the class is not loaded again.

I checked the sources in Apache's CVS. I noticed that there is quite some debugging put into
WebappClassLoader. But I can't get my server to log these messages. I have the log4j and commons
logging jars in my common\lib directory and my (root logger set to debug)
in my common\classes directory. I also set the debug to "4" everywhere in my server.xml.
I see some catalina debug messages, but I cannot see the messages from the WebappClassLoader.
So what am I doing wrong? I believe the debug output would be very helpful in understanding
the problem.


> -----Original Message-----
> From: delbd [] 
> Sent: Thursday, June 02, 2005 12:33 PM
> To: Tomcat Users List
> Subject: Re: WebappClassLoader - don't understand what's happening
> This indeed should not happen as this would break sun specs. 
> I would be quite surprised it it was at all possible :/ How 
> did you conclude the webappclassloader is sharing the class 
> between webapps in your case?
> Are you sure you are not mistakenly using a shared class?
> Not only does every webapp has his very own 
> webappclassloader, but if you reload the webapp (using the 
> manager/html interface) this should also create a new 
> webclassloader and reload all classes (did you check it was 
> the case?).
> Am also using tomcat 5.5.7 here, with jdk 1.4.2_05-b04 and we 
> didn't notice such a problem. We can deploy several webapps, 
> all using a library in WEB-INF/lib which is crating 
> singletons. All webapp has it's own sets of singletons.
> Could it be that you are in fact doing such scenario?
> - create an object of class A in webapp1 using webappclassloader1
> - push this object to some library shared between webapplications
> - retrieve the object from shared library in webapp2 (as this 
> is via a shared library, it's possibile to do and you and up 
> manipulating in webapp2 an object who's classloader is 
> webappclassloader1)
> - in webapp2, calls something like a.createB() to get an 
> object of class B and be surprised that the class of B was 
> created using webappclassloader1
> Le Jeudi 2 Juin 2005 10:59, Herrmann, Sascha (GE Healthcare) a écrit :
> > We are facing a problem with Tomcats WebappClassLoader.
> > We deploy several of our own applications on one Tomcat server.
> >
> > It seems that the WebappClassLoaderS are not isolated but share 
> > classes instead. Why would that be?
> >
> > Judging from the (well, outdated) classloader documentation, this 
> > should never happen.
> > If an application tries to use a class, and the class is in 
> a jar in 
> > its WEB_INF\lib directory, then the class should be loaded by the 
> > application's very own WebappClassLoader. It should not be 
> available 
> > to other WebappClassLoaderS, isn't that correct? I quote:
> >
> > "All unpacked classes and resources in the /WEB-INF/classes 
> directory 
> > of your web application archive, plus classes and resources in JAR 
> > files under the /WEB-INF/lib directory of your web application 
> > archive, are made visible to the containing web 
> application, **but to no others**."
> >
> > Instead of sharing the class, the second WebappClassLoader 
> should load 
> > the class again, shouldn't it?
> > So why does a WebappClassLoader here re-use a class already 
> loaded by 
> > the WebappClassLoader of another application?
> >
> > We're running 5.5.7 on JDK 142_08.
> >
> > Thanks in advance!
> >
> >
> > Sascha Herrmann
> > Engineering (Java)
> > GE Healthcare
> > Technologies
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> --
> David Delbecq
> Royal Meteorological Institute of Belgium
> -
> Is there life after /sbin/halt -p?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message