This component (let's call it RulesService) is part of the EAR.
Basically what happens is that it is loaded in a separate class loader, and those classes load lazily the RuleBaseConfiguration when the first request hits my webapp which calls this RulesService.
So the CompositeClassLoader has a reference to the webapp class loader because it happens in the context of the request Thread, and it is referenced by objects of RulesService which outlive my webapp.

I have decided to intercept the initialization of my webapp, nullify the context class loader and force the initialization of RulesService and reset the context class loader.
This is also what Mark just suggested, except that my code is not responsible of initializing the Drools classes so I had to trick RulesService into doing it.

This should do it for now.

Thanks,
Romain





From:        Davide Sottara <dsotty@gmail.com>
To:        rules-users@lists.jboss.org,
Date:        06/04/2014 02:10
Subject:        Re: [rules-users] Memory leak due CompositeClassLoader
Sent by:        rules-users-bounces@lists.jboss.org

---

I think I'm starting to see the problem now. Where does this "component" live
exactly, and how is that (and the KB) shared between your different webapps?



--
View this message in context: http://drools.46999.n3.nabble.com/rules-users-Memory-leak-due-CompositeClassLoader-tp4029053p4029131.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users