Hehe.. after sending the email I realize that it means to set that parameter each time that you want to correct that in the JVM.. I will look for alternatives.. I would like to know if someone else using a different OSGI container or at least equinox in another context with JVM 6 has the same problem.
I will try to replicate the same issue in other environment to see if we can get rid of the problem in a standard way. Cheers On Fri, Nov 18, 2011 at 3:45 PM, Mark Proctor <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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=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 >> > >> > >> >> >> >> -- >> - 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 - _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
