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