WebappClassLoader - don't understand what's happening

["Herrmann, Sascha (GE Healthcare)" <Sa...@med.ge.com>]

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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

Re: WebappClassLoader - don't understand what's happening

[delbd <de...@oma.be>]

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: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

-- 
David Delbecq
Royal Meteorological Institute of Belgium

-
Is there life after /sbin/halt -p?

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org