Based on more tests and reading some articles about OSGI we (Professor dotty and I) have found thatthe composite class loader from drools is using Class.forName that is being intercepted by the equinox OSGI container ->
at org.eclipse.core.runtime.internal.adaptor.ContextFinder.loadClass(ContextFinder.java:124)
It looks like both are trying to load the same class definition and the JVM throws the ClassCircularityError.
For my very basic example changing the CompositeClassLoader implementation to use:
cls = classLoader.loadClass(name);
instead of:
cls = Class.forName( name,
resolve,
classLoader );
Fix the problems. But I'm not sure if that will work for all the other cases.
Looking the usages of Class.forName inside compiler, core and api I found that it is being used 39 times, which worries me.
I'm not planning to change all of them without being sure that is the right way to go. I will continue reading and testing to see if changing the way of loading the classes is the only alternative.
Some notes about the difference between loadClass and forName:
- Classloader.loadClass() caches the loaded class
object and returns always the same class object
- This is done by the defining class loader
- This ensures that each classloader loads the same class only once
- Class.forName() calls the normal classloader
hierarchy to load the class (same happens as above)
- But caches the class object within the initiating
class loader
- In standard cases no problem but can be tricky in dynamic
environments