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/
________________________________________________________________
