Re: [rules-dev] [rules-users] class loading problems with 5.3.0-Final and 5.4.0-SNAPSHOT

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 <salaboy(a)gmail.com&gt; 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 <mproctor(a)codehaus.org&gt; 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 <salaboy(a)gmail.com&gt; >> 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-ClassloadingTypeVisibilityOS... >>> On Tue, Nov 15, 2011 at 4:04 PM, Davide Sottara <dsotty(a)gmail.com&gt; 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... >>> > Sent from the Drools: User forum mailing list archive at Nabble.com. >>> > _______________________________________________ >>> > rules-users mailing list >>> > rules-users(a)lists.jboss.org >>> > 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 >>> rules-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> 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 rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev