Your words make sense to me, too.
--
Bongjae Chang
----- Original Message -----
From: Hubert Iwaniuk
To: dev_at_grizzly.dev.java.net
Sent: Monday, August 31, 2009 11:38 PM
Subject: Re: About ServletAdapter's classloader
Hi,
Inline.
I think what we want is
ThreadClassloader
/ \
ServletAdapterA_CL ServletAdapterB_CL
two ServletAdapter instance will have their own Classloader referencing their web-inf/lib or classes directory, but they will share a common based. Does it help?
I understood your word just now. You are right.
Current ServletAdapter to which I applied the patch doesn't have your classloader hierarchy.
The current classloader hierarchy is here.
--------
ServletAdapterA_CL's parent ServletAdapterB_CL's parent
/ \
ServletAdapterA_CL ServletAdapterB_CL
--------
But, I also think that the parent classloader should be not their own Classloader's parent CL but common ThreadClassloader.
Agree.
Should we really take care of CL hierarchy in ServletAdapter?
IMHO it is enough that we have SA.setCL(...). So different applications can set different CL for SA, and by that also different hierarchies.
So for case of GWSD we'll create following classloaders:
ServerLibClassLoader (parent)
|-- WebApp1ClassLoader
\-WebApp2ClassLoader
And each WebAppAdapter will take care of setting WebApp1ClassLoader or WebApp2ClassLoader on different SAs depending on weather Servelt is coming from WebApp1 or WebApp2.
So I don't see need for SA to build it's own CL hierarchy.
What use case I'm missing?
For your classloader hierarchy, maybe I think that we should make new ClassLoader and should override ContextLoader#loadClass() and findClass().
Am I understanding it correctly?
Just to make sure, you propose to override those methods to isolate the web application classes?
If that is the case, than GWSD is perfectly suited for creating this isolation w/o introducing new entity.
Hubert.