[rules-dev] ClassLoader Improvements and OSGi

[Michael Anstis]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101204/5d038697/attachment-0001.html