Re: [rules-dev] ClassLoader Improvements and OSGi

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev