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 directories.
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 log4j.properties (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.

Sascha
 

> -----Original Message-----
> From: delbd [mailto:[EMAIL PROTECTED] 
> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> --
> David Delbecq
> Royal Meteorological Institute of Belgium
> 
> -
> Is there life after /sbin/halt -p?
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to