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?

regards
Leon

On 8/5/07, Johnny Kewl <john@(protected):
>   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 happening.
>
> 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>kewlstuff.co.za -- replace <No Spam> with @ --
>  Cell: +027-72- 473-9331
> Java Developer (Tomcat Aficionado)
>  Free Tomcat software at http://coolese.100free.com/
> ________________________________________________________________

---------------------------------------------------------------------
To start a new topic, e-mail: users@(protected)
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)