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 <mproctor@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