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

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-ClassloadingTypeVisibilityOSGi.pdf >> 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 -

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=2a9a78e4393c5e678a... Mark On Thu, Nov 17, 2011 at 5:53 PM, Mauricio Salatino <salaboy(a)gmail.com&gt; 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 <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-ClassloadingTypeVisibilityOSGi.pdf > >>> 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 _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

We can't start saying to people "Drools only works if you remember to turn on some JVM setting". It'll smell bad, too fragile. For now Class.forName stays, you'll need to find other work arounds. Mrk On Fri, Nov 18, 2011 at 5:27 PM, Mauricio Salatino <salaboy(a)gmail.com&gt; wrote: > > There are two workarounds mentioned there and one of them is: > > 1. setting an environment variable when starting VM: > -Dsun.lang.ClassLoader.allowArraySyntax=true. > > Instead of using the Class.forName() method. That looks like something > that we can add in a profile right? it's just a JVM configuration > issue. > > This looks to be a problem only in JDK 6. > If we are using Class.forName() in an OSGI environment that provides > hooks for Class.forName() we will end up having troubles with the > CompositeClassLoader. > > What do you think about that? I'm trying to decide and find out what > are the most appropriate next steps. > > Cheers > > > On Fri, Nov 18, 2011 at 2:15 PM, Mark Proctor <mproctor(a)codehaus.org&gt; > wrote: > > 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=2a9a78e4393c5e678a... > > > > Mark > > On Thu, Nov 17, 2011 at 5:53 PM, Mauricio Salatino <salaboy(a)gmail.com&gt; > > 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 <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-ClassloadingTypeVisibilityOSGi.pdf > >> >>> 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 > > > > > > _______________________________________________ > > 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 - > > _______________________________________________ > 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

This BUG goes into more detail about the issue, and from the language i'm guessing this is still true in Java7 and they have no intention of changing it. They don't consider it a bug, just people abusing unspecified behaviour of it in the past. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212 "There was never any design intent for it to succeed and we haven't seen any scenario where it makes sense though we've recieved many reports of cases where users have come to expect it to succeed. ... snip... Generally speaking reflective loading of a class by name should be accomplished by using this static method in java.lang.Class:   public static Class<?> forName(String name, boolean initialize, ClassLoader loader)       throws ClassNotFoundException The ClassLoader.loadClass() method is more typically used for class loader delegation.  Invocation of Class.forName() may eventually invoke ClassLoader.loadClass() after handling VM name resolution.  In particular, for array classes, this would involve loading the array's component type. Thus, we highly recommend replacement of this code:   myClassLoader.loadClass(className); With this code:   Class.forName(className,false,myClassLoader);" On Fri, Nov 18, 2011 at 6:45 PM, Mark Proctor <mproctor(a)codehaus.org&gt; wrote: > > We can't start saying to people "Drools only works if you remember to turn > on some JVM setting". It'll smell bad, too fragile. > > For now Class.forName stays, you'll need to find other work arounds. > > Mrk > On Fri, Nov 18, 2011 at 5:27 PM, Mauricio Salatino <salaboy(a)gmail.com&gt; > wrote: >> >> There are two workarounds mentioned there and one of them is: >> >> 1. setting an environment variable when starting VM: >> -Dsun.lang.ClassLoader.allowArraySyntax=true. >> >> Instead of using the Class.forName() method. That looks like something >> that we can add in a profile right? it's just a JVM configuration >> issue. >> >> This looks to be a problem only in JDK 6. >> If we are using Class.forName() in an OSGI environment that provides >> hooks for Class.forName() we will end up having troubles with the >> CompositeClassLoader. >> >> What do you think about that? I'm trying to decide and find out what >> are the most appropriate next steps. >> >> Cheers >> >> >> On Fri, Nov 18, 2011 at 2:15 PM, Mark Proctor <mproctor(a)codehaus.org&gt; >> wrote: >> > 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=2a9a78e4393c5e678a... >> > >> > Mark >> > On Thu, Nov 17, 2011 at 5:53 PM, Mauricio Salatino <salaboy(a)gmail.com&gt; >> > 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 <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-ClassloadingTypeVisibilityOSGi.pdf >> >> >>> 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 >> > >> > >> > _______________________________________________ >> > 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 - >> >> _______________________________________________ >> 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