[rules-dev] [rules-users] class loading problems with 5.3.0-Final and 5.4.0-SNAPSHOT
Mark Proctor
mproctor at codehaus.org
Fri Nov 18 13:57:33 EST 2011
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 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20111118/57746eda/attachment-0001.html
More information about the rules-dev
mailing list