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