Thanks for reporting this, along with the sample, the very clear steps for reproducing the issue, and the analysis. I'll take a look at this later today - hopefully we can track this down and fix it without too much trouble.
Jon On Mon, Oct 14, 2019 at 9:00 AM makkus <sancho-...@gmx.de> wrote: > 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 >
