This is the jira that links to the java issue that explains why we can't use loadClass, the bug is still active, so we have to keep Class.forName https://issues.jboss.org/browse/JBRULES-1553 http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=2a9a78e4393c5e678a2c80f90c1?bug_id=6434149
Mark On Thu, Nov 17, 2011 at 5:53 PM, Mauricio Salatino <[email protected]>wrote: > Just a small update: > If I compile core and compiler with tests I'm just getting the > following failing tests in compiler: > Failed tests: > > testMonitorResourceChangeEvents(org.drools.agent.KnowledgeAgentDisposeTest) > testDispose(org.drools.agent.KnowledgeAgentDisposeTest) > > Tests in error: > > > testAccumulateMultipleFunctionsJava(org.drools.integrationtests.AccumulateTest) > > > testAccumulateMultipleFunctionsMVEL(org.drools.integrationtests.AccumulateTest) > testAccumulateMinMax(org.drools.integrationtests.AccumulateTest) > testAccumulateCE(org.drools.integrationtests.AccumulateTest) > > I think that the knowledge agents problem is not related with the > Class.forName() change, but all the failing test inside the > AccumulateTest fails because the following line inside > ClassFieldAccessorCache: > 124: return this.classLoader.loadClass( className ); > > Debugging, I didn't find the reason of the following stack trace: > org.drools.RuntimeDroolsException: Unable to resolve class > '[Ljava.lang.Object;' > at > org.drools.base.ClassFieldAccessorCache.getClass(ClassFieldAccessorCache.java:126) > at > org.drools.base.ClassFieldAccessorCache.getClassObjectType(ClassFieldAccessorCache.java:48) > at > org.drools.base.ClassFieldAccessorStore.getClassObjectType(ClassFieldAccessorStore.java:285) > at > org.drools.base.ClassFieldAccessorStore.getClassObjectType(ClassFieldAccessorStore.java:271) > at > org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:291) > at > org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:130) > at > org.drools.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:65) > at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:80) > at > org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:2302) > at > org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:823) > at > org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:405) > at > org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:587) > at > org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:37) > at > org.drools.integrationtests.AccumulateTest.loadKnowledgeBase(AccumulateTest.java:111) > at > org.drools.integrationtests.AccumulateTest.execTestAccumulateMultipleFunctions(AccumulateTest.java:1656) > at > org.drools.integrationtests.AccumulateTest.testAccumulateMultipleFunctionsJava(AccumulateTest.java:940) > > Because the community hudson is down I can't check if it's a local > problem or a master one. > > Cheers > > > > On Wed, Nov 16, 2011 at 5:48 PM, Mauricio Salatino <[email protected]> > wrote: > > We really need to analyze the difference and understand what is > > happening under the hood.. because if not strange things can happen. > > I will run the tests locally to see if I see something wrong. > > > > Cheers > > > > On Wed, Nov 16, 2011 at 5:46 PM, Mark Proctor <[email protected]> > wrote: > >> We original used classLoader.loadClass but then there was wierd bug with > >> dynamic rules that wouldn't work, related to arrays. Switching to > >> Class.forName avoided that bug. But I don't remember the exact details, > it > >> was several years ago now. > >> > >> Mark > >> > >> On Wed, Nov 16, 2011 at 5:50 PM, Mauricio Salatino <[email protected]> > >> wrote: > >>> > >>> Based on more tests and reading some articles about OSGI we (Professor > >>> dotty and I) have found that > >>> the 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 > >>> > >>> Source > >>> -> > http://www.martinlippert.org/events/WJAX2008-ClassloadingTypeVisibilityOSGi.pdf > >>> On Tue, Nov 15, 2011 at 4:04 PM, Davide Sottara <[email protected]> > wrote: > >>> > > >>> > Lovely exception... > >>> > Well, both my life and salaboy's depend on solving this issue... Mark > >>> > and I > >>> > were also considering to review the Composite ClassLoader at some > point > >>> > in > >>> > the future, since it causes issues with (re)declared types in DRLs > >>> > loaded at > >>> > runtime. Looks like we'll have to catch two birds with one stone :) > >>> > Salaboy, can you share the simple service and the WSO2 config > details? > >>> > (version, any custom setting, etc...) > >>> > > >>> > -- > >>> > View this message in context: > >>> > > http://drools.46999.n3.nabble.com/rules-users-class-loading-problems-with-5-3-0-Final-and-5-4-0-SNAPSHOT-tp3509949p3510640.html > >>> > Sent from the Drools: User forum mailing list archive at Nabble.com. > >>> > _______________________________________________ > >>> > rules-users mailing list > >>> > [email protected] > >>> > https://lists.jboss.org/mailman/listinfo/rules-users > >>> > >>> > >>> > >>> -- > >>> - CTO @ http://www.plugtree.com > >>> - MyJourney @ http://salaboy.wordpress.com > >>> - Co-Founder @ http://www.jugargentina.org > >>> - Co-Founder @ http://www.jbug.com.ar > >>> > >>> - Salatino "Salaboy" Mauricio - > >>> > >>> > >>> > >>> -- > >>> - CTO @ http://www.plugtree.com > >>> - MyJourney @ http://salaboy.wordpress.com > >>> - Co-Founder @ http://www.jugargentina.org > >>> - Co-Founder @ http://www.jbug.com.ar > >>> > >>> - Salatino "Salaboy" Mauricio - > >>> > >>> _______________________________________________ > >>> rules-dev mailing list > >>> [email protected] > >>> https://lists.jboss.org/mailman/listinfo/rules-dev > >> > >> > >> _______________________________________________ > >> rules-dev mailing list > >> [email protected] > >> https://lists.jboss.org/mailman/listinfo/rules-dev > >> > >> > > > > > > > > -- > > - CTO @ http://www.plugtree.com > > - MyJourney @ http://salaboy.wordpress.com > > - Co-Founder @ http://www.jugargentina.org > > - Co-Founder @ http://www.jbug.com.ar > > > > - Salatino "Salaboy" Mauricio - > > > > > > -- > - CTO @ http://www.plugtree.com > - MyJourney @ http://salaboy.wordpress.com > - Co-Founder @ http://www.jugargentina.org > - Co-Founder @ http://www.jbug.com.ar > > - Salatino "Salaboy" Mauricio - > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev >
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
