Le Jeudi 2 Juin 2005 13:49, Herrmann, Sascha (GE Healthcare) a écrit :
> Thanks for your reply.
>
> It could be. How is a class "pushed" to a shared library?

Any library having static methods like 
SomeLibraryClass.setXYZ(xyz);
SomeLibraryClass.getXYZ(xyz);

>
> 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
> ***************************************" );
>

Tss tss tss, the Threads instances are started by catalina-http and shared 
inside a Thread pool amongst tomcat application if am not wrond, so i doubt 
usefull informations comes from it. 
Only usefull information should comes from 
BoneDBTransactionImpl2.class.getClassLoader() as this is the classloader 
which will load any class needed by BoneDBTransactionImpl2.


> 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.

Strange indeed, so you mean when starting app B, the static block of 
BoneDBTransactionImpl2 is never executed? If that's the case this indeed mean 
the class was already loaded before. Either this mean you have another lib in 
webapp B requiring BoneDBTransactionImpl2 and you didn't see the static init 
message 50 lines before ;), either you indeed have something shared.

One easy way to check
In webapp A, create a servelt which will set to 1 a static boolean in 
BoneDBTransactionImpl2 and in webapp B, set another servlet which will read 
the value of this boolean. 
first access B servlet to ensure boolean is set to false
acces A servlet to switch boolean to true
re-access B servlet to check if boolean has switched value in B webapp

If that's the case, this really mean class is shared by webapp class loaders, 
serious problems ahead for tomcat team ;)



>
> 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?
>

dunno

> 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.
>

me too ;) however, separation in webapps mean every ressource in a .war is not 
to be shared with any other webapp.


> 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.

see message above, i just didn't know how you concluded the class was shared, 
one common error is to give an instance of some object to a shared library 
and retreive it in another webapp, not understanding this object you are 
manipulating is a stranger ;) not your case scenario you describe.

>
> 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.

Yes have same problem here to get usefull log messages from Realms. Seems you 
have to modify directly the logging level in your java home, 
logging.properties (and setting it to debug for whole jvm is VERY verbose)

>
> 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]

-- 
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]

Reply via email to