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.