WAR == single classloader was: Benefits of activeReferenceQueue

[David M. Lloyd]

On 08/04/2014 06:27 AM, Florian Weimer wrote:
> On 08/01/2014 06:39 AM, Jaroslav Tulach wrote:
>> Dne Út 29. července 2014 14:13:25, Florian Weimer napsal(a):
>>> On 07/29/2014 10:05 AM, Jaroslav Tulach wrote:
>>>> Plus, because there is a single classloader which loads all the classes
>>>> from a WAR, by keeping the activerReferenceQueue thread alive and
>>>> holding
>>>> reference to the queue, we hold reference to its class and the
>>>> classloader and thus all classes referenced by it.
>>>>
>>>> And this memory leak accumulates with every re-deploy.
>>>
>>> Could you interrupt the thread when URLClassLoader#close() is called?
>>
>> Hello Florian,
>> I am not sure how to hook into URLClassLoader#close? It is the
>> container who
>> creates the classloader, not my library and I don't see any way to add a
>> "listener" to the close method (without a reflection).
>
> Wouldn't it be the job of the container to provide such notification
> just before unloading the module?
>
> I wonder if it is possible to fake such notification with finalization
> which is triggered after class unloading, but it seems this needs
> separate class loaders and will likely be rather brittle.

Servlets are EE components, and as such, you should be able to establish 
a @PreDestroy interceptor, which was introduced for exactly this kind of 
purpose (cleanup and reclaiming of per-component resources).  Also 
servlets have a destroy method IIRC.

IOW all of this seems unnecessary.

-- 
- DML