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 <[EMAIL PROTECTED]> 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 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@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
