Hi folks, by tracing down a classloader leak in my webapp I realized, that leaks are actually created by activating CDI via adding the "beans.xml" into WEB-INF (TomEE plume 8.0.0-M2 and TomEE plume 8.0.0). To reproduce, I have created a minimalistic jsf enabled webapp consiting of onyl a simple ServletContextListener (called leaktest.AppContextListener). Feel free to download the test war archive here: https://1drv.ms/u/s!AlHB9FAlFWW_iLJjPO5NAk77apcO4g?e=gjFDoY
When reloading the application inside tomcat multiple times and stopping it, for each load one leaktest.AppContextListener class reference can be found in the heapdump classes <http://tomee-openejb.979440.n4.nabble.com/file/t376354/leakWithBeans.jpg> When renaming "beans.xml" into something invalid like "_beans.xml" the classloader leak disappears, only a single leaktest.AppContextListener class can be found in the heapdump after the app is stopped. Tomcats leak detection button confirms this observation. Without CDI enabled (i.e. invalid "_beans.xml") the leak message inside the manager app lists only a single line (even with repreated reloads). With CDI enabled (valid beans.xml) for each reload an new line is added in the leak message window of the tomcat web application manager. Can anybody confirm this? Or has anyone successfully deployed a non-classloader-leaking CDI enabled webapp to TomEE? Regards, Marcus -- Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html
