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

[Mark Proctor]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20111116/3eb305e5/attachment.html