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.
"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> 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>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>
> 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>
> > 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>
> >> 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
> >
> >> > 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>
> >> >> 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>
> >> >>> 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
>