Re: [rules-dev] [rules-users] class loading problems with 5.3.0-Final and 5.4.0-SNAPSHOT

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&gt; 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(a)gmail.com&gt; 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