[rules-dev] [rules-users] class loading problems with 5.3.0-Final and 5.4.0-SNAPSHOT
Mauricio Salatino
salaboy at gmail.com
Fri Nov 18 13:54:11 EST 2011
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 <mproctor at codehaus.org> 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 at gmail.com>
> 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 at codehaus.org>
>> 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 <salaboy at gmail.com>
>> > 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 at gmail.com>
>> >> 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 at codehaus.org>
>> >> > 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 at gmail.com>
>> >> >> 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 at gmail.com>
>> >> >>> 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
>> >> >>> > rules-users at 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 at lists.jboss.org
>> >> >>> https://lists.jboss.org/mailman/listinfo/rules-dev
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> rules-dev mailing list
>> >> >> rules-dev at 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 at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/rules-dev
>> >
>> >
>> > _______________________________________________
>> > rules-dev mailing list
>> > rules-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at 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 -
More information about the rules-dev
mailing list