It'd be great to learn a little more about Drools' class loading strategy; where it's come from and where it is now.
Can anyone explain more about Drools class loading? I can guess the RETE network needs to know how to load classes declared in rules; however this no doubt is the tip of an iceberg. Thanks, Mike On 4 December 2010 04:53, Mark Proctor <mproc...@codehaus.org> wrote: > I have done more cleaning up in the ClassLoader stuff. > > While we added a root CompositeClassLoader recently there was still > another alternative composite ClassLoader implementation that was used > by the Packages. So we ended up with a composite CL being added to > another CL. Both composites had their own caching etc. > > So now we have single CompositeClassLoader, with a single point of > caching and slightly improve coding at detecting Drools specific CLs. My > hope is that the code is also more efficient. > > This work was done due to another OSGi requirement where each module > needs to add itself to the root classloader. But sometimes it was > returning the root CL, or sometimes the package level composite CL. So > now there is only one and that should no longer happen. > > What this means is that any module that will have it's classes resolved > via reflection from other modules should in their constructor or other > initialisation of the code do something like > getRootClassLoader().addClassLoader( getClass().getClassLoader() ). In > situations where it's a single container all modules have the same > classloader and the call gets ignored, as it won't re-added an existing > CL. In the OSGi case it'll add the classloader and now classes from that > module can be resolved in an OSGi environment. > > Mark > > _______________________________________________ > rules-dev mailing list > rules-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev >
_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
