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@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@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@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@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@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@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@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@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@lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/rules-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> rules-dev mailing list
>> >> rules-dev@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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev