Extended Search for Classes Loaded from WebAppClassLoader about classloader-leak-prevention HOT 4 CLOSED

Hi Kenny. I don't think we want to go down this path. If we do, why only stop there? What if the ThreadLocal value is a Map that contains objects that has List attributes that contains elements loaded in the web app (and so forth)?

I'm leaning towards, in this case you should primarily fix the source of the leak (clear the ThreadLocal), or write some custom code for the particular leak. I haven't quite decided yet, though.

Do you have any further arguments for making the suggested changes part of the core functionality? Would it benefit if you provided more details of your case? Was it third party library or in house code?

from classloader-leak-prevention.

Hi,

We experienced the problem with a third-party library, hence why we added it to an extension we did of your library.

If I'm not mistaken the dependency was somewhere deep inside one of the libraries we relied upon. and was quite hard to fix directly. I don't seem to remember exactly which one though since I wrote this code already 6-7 months ago before picking it up again and now submitting it towards you.

I'll attempt to dig up what exactly was the reasoning why we had to make this change.

from classloader-leak-prevention.

A link to a bug report on the offending third party library would be great!

from classloader-leak-prevention.

I seem to be unable to find it back, this can be closed.

from classloader-leak-prevention.