tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leon Rosenberg" <>
Subject Re: Per Thread Class Loader... what do you think?
Date Sun, 05 Aug 2007 10:38:22 GMT
could you elaborate a bit more why do you need the classloader to be per thread?
In case that you really really need your own classloader for _some_
objects, why don't you create a global classloader and load only those
classes from it? why replace thread-classloader back and forth?


On 8/5/07, Johnny Kewl <> wrote:
>     public void doPost(HttpServletRequest request, HttpServletResponse response)
>     throws ServletException, IOException {
>        //=======new DoServiceClass().doService(request, response)========
>         ClassLoader origClassLoader = Thread.currentThread().getContextClassLoader();
>         ExClassLoader localClassLoader = new ExClassLoader(origClassLoader);
>         String repository = dock.getRepository();
>         localClassLoader.setRepository(repository);
>         Thread.currentThread().setContextClassLoader(localClassLoader);
>         doServiceMain(request, response);
>         Thread.currentThread().setContextClassLoader(origClassLoader);
>       //======================================================
>     }
> This snippet of code is actually wrapped in new DoServiceClass().doService(request, response)
for thread safety reasons.
> ie in doPost.... this is called       new DoServiceClass().doService(request, response);
> But its shown as above because its "easier" to appreciate the complexity of whats actually
> What is does is swap Tomcats classloader, to an Extended class loader... on every thread....
and then after processing the thread gives TC its own class loader back.
> It seems to work, but its seriously complex stuff, I'm building a per thread container
on top of TC's container, and I'm wondering if this is the right way to do it.
> More I think about this...... more confused I get....
> From a "pure" coding point of view.... it is thread safe, but I wonder how tomcat deals
with its classloader being reassigned on every thread.
> Any comments on whether you think this is the right or wrong way... appreciated... thx
> Just a comment....
> From playing with classloaders, one thing I've found is that if you want to test how
good an underlying containers classloader is, make it run an application that uses its own
classloaders.... case in point, WebStart fails miserably when you do this.
> Tomcat seems to be rock solid, during testing sometimes this app I'm building has 20
different classloaders open in the webapp, and as you can see, another classloader per thread,
and in some cases stacked parent child classloaders..... TC is rock solid.
> If you wondering why I need my own classloader at thread level, its because this application
does things like serialize objects and special http RMI.... the serialization of objects from
client to server and back to client is why I need it.... if I serialize on the WebApps class
loader, and provide the object template from my class loader, the object will never release
from my class loader.... I'm actually not sure why this is.... but it seems that if the code
is run from classes in one classloader, and the template object is provided from another....
theres a cross classloader dependency that prevents garbage collection....probably because
TC's classloader is picking up the Serializable interface, and the object doesnt come from
the same classloader..... thus the need to do the above.... Tomcat at the extreme ;)
> So, what do you think... ok... or crazy ;)
> ________________________________________________________________
> Johnny Kewl
>   eMail: John<No Spam>  -- replace <No Spam> with @ --
>   Cell: +027-72- 473-9331
> Java Developer (Tomcat Aficionado)
>   Free Tomcat software at
> ________________________________________________________________

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message