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 <dso...@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-boun...@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
_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
