[rules-users] class loading problems with 5.3.0-Final and 5.4.0-SNAPSHOT
by Mauricio Salatino
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> 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 -
12 years, 5 months
Guvnor: Work in progresss - Guided Decision Table editor and Template Data editor
by Michael Anstis
I am refactoring the mergable grid widget, used by the captioned, to an
event-based design and have pushed changes to the master branch in github.
I pushed the changes as Jervis Liu is completing a major re-organisation of
the Guvnor code-base this week and I didn't want to end up with merge
conflict hell :)
The changes, at this stage, are incomplete. Consequently the captioned
editors do not fully work at the moment in the master branch. 5.3.0.Final
is unaffected.
So, if you get the latest code github's master branch be warned. My changes
will complete this week or early next.
With kind regards,
Mike
12 years, 5 months
class loading problems with 5.3.0-Final and 5.4.0-SNAPSHOT
by Mauricio Salatino
Hi guys,
I'm working here trying to find out a little problem that I'm having with
Drools 5.4.0-SNAPSHOT and 5.3.0-Final.
I'm using WSO2 container to deploy a very simple service and when a rule
gets activated the following exception appears (with 5.4.0-SNAPSHOT):
Exception in thread "Thread-44" java.lang.ClassCircularityError:
org/drools/rule/builder/dialect/asm/ConsequenceGenerator
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at
org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:262)
at
org.drools.util.CompositeClassLoader.loadClass(CompositeClassLoader.java:105)
at
org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:540)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at
org.eclipse.core.runtime.internal.adaptor.ContextFinder.loadClass(ContextFinder.java:124)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at
org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:262)
at
org.drools.util.CompositeClassLoader.loadClass(CompositeClassLoader.java:105)
at
org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:540)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at
test.Rule_request_bed_ede4a687c29740c8bb9f13968941e6a1DefaultConsequenceInvoker.evaluate(Unknown
Source)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1091)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1029)
at org.drools.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1229)
at
org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:756)
at
org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:732)
at
org.drools.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:234)
at
com.wordpress.salaboy.hospital.HospitalServiceImpl$1.run(HospitalServiceImpl.java:71)
I'm worried to see that I don't have any problems with 5.1.1 but with later
version all throw similar issues.
I will be trying to solve this issue, but if someone has a clue about what
can be happening here, please let me know.
I know that this can be a particular issue with WSO2, but it looks like
something has changed inside drools.
Cheers
--
- 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 -
12 years, 5 months
Problem setting up Guvnor to run in hosted mode in eclipse
by Mikael Lönneberg
Hi,
I hope one of you nice people will be able to help.
I'm trying to setup Guvnor for development and debugging in eclipse in
hopes of being able to contribute. However I have spent a couple of days
now trying to get it setup but I keep running into problems.
Now when I try to run it I get
Loading modules
org.drools.guvnor.FastCompiledGuvnor
Loading inherited module 'org.drools.guvnor.Guvnor'
[ERROR] Unable to load class
'org.drools.guvnor.gwtutil.PerspectiveFactoryGenerator'
java.lang.ClassNotFoundException:
org.drools.guvnor.gwtutil.PerspectiveFactoryGenerator
Full stacktrace is included in an attachment. I get the same error when I
run mvn gwt:compile on the command line.
mvn clean install -DskipTests runs fine without errors and reporting
success.
Any pointers to other guides that I could follow apart from the
droolsjbpm-build-bootstrap/readme
Kind Regards
Mikael Lönneberg (gwendo)
12 years, 5 months
Rules compilation and unnecessary attempts to getResourceAsStream()
by Leonardo Gomes
Hi Guys,
First of all, congrats for the 5.3 release!
I was having a look at the recent improvements done to rules compilation,
mentioned here<http://docs.jboss.org/drools/release/5.3.0.Final/droolsjbpm-introduction-...>,
and I unfortunately couldn't really realize a 3 times faster compilation :(
After some profiling, my problem seems to come from
some unsuccessful attempts to getResourceAsStream done
at org.drools.commons.jci.compilers.EclipseJavaCompiler. Basically on line
218, to be able to know if something is a type or not, it will get
a supposedly class name and try to load it, if it cannot be loaded then it
will infer that what it thought was a class was actually a package.
Here goes a call stack, to give some context. In this particular case, the
string parameter was "com.sample.org", thus not a type.
EclipseJavaCompiler$2.findType(String) line: 220
> EclipseJavaCompiler$2.findType(char[], char[][]) line: 215
> LookupEnvironment.askForType(PackageBinding, char[]) line: 127
> PackageBinding.getTypeOrPackage(char[]) line: 183
> MethodScope(Scope).getTypeOrPackage(char[], int, boolean) line: 2592
> MethodScope(Scope).getPackage(char[][]) line: 2266
> QualifiedTypeReference.getTypeBinding(Scope) line: 69
> QualifiedTypeReference(TypeReference).internalResolveType(Scope) line: 130
> QualifiedTypeReference(TypeReference).resolveType(BlockScope, boolean)
> line: 197
> SourceTypeBinding.resolveTypesFor(MethodBinding) line: 1370
> SourceTypeBinding.methods() line: 1090
> SourceTypeBinding.faultInTypesForFieldsAndMethods() line: 593
> CompilationUnitScope.faultInTypes() line: 447
> Compiler.process(CompilationUnitDeclaration, int) line: 752
> Compiler.compile(ICompilationUnit[]) line: 464
> EclipseJavaCompiler.compile(String[], ResourceReader, ResourceStore,
> ClassLoader, JavaCompilerSettings) line: 358
> EclipseJavaCompiler(AbstractJavaCompiler).compile(String[],
> ResourceReader, ResourceStore, ClassLoader) line: 49
> JavaDialect.compileAll() line: 369
> DialectCompiletimeRegistry.compileAll() line: 53
> PackageRegistry.compileAll() line: 71
> PackageBuilder.compileAll() line: 869
> PackageBuilder.addPackage(PackageDescr) line: 826
> PackageBuilder.addPackageFromDrl(Resource) line: 404
> PackageBuilder.addKnowledgeResource(Resource, ResourceType,
> ResourceConfiguration) line: 586
> KnowledgeBuilderImpl.add(Resource, ResourceType) line: 37
> DroolsTest.readKnowledgeBase() line: 52
> DroolsTest.main(String[]) line: 25
On the same lines, method isPackage on line 285, will try to load a "class
name" and if it can't be found it will assume it was actually a package
name and return true.
Again, an illustrative call stack:
>
> CompositeClassLoader.getResourceAsStream(String) line: 128
> EclipseJavaCompiler$2.isPackage(String) line: 288
> EclipseJavaCompiler$2.isPackage(char[][], char[]) line: 318
> LookupEnvironment.isPackage(char[][], char[]) line: 1262
> PackageBinding.findPackage(char[]) line: 77
> PackageBinding.getTypeOrPackage(char[]) line: 196
> MethodScope(Scope).getTypeOrPackage(char[], int, boolean) line: 2592
> MethodScope(Scope).getPackage(char[][]) line: 2266
> QualifiedTypeReference.getTypeBinding(Scope) line: 69
> QualifiedTypeReference(TypeReference).internalResolveType(Scope) line: 130
> QualifiedTypeReference(TypeReference).resolveType(BlockScope, boolean)
> line: 197
> SourceTypeBinding.resolveTypesFor(MethodBinding) line: 1370
> SourceTypeBinding.methods() line: 1090
> SourceTypeBinding.faultInTypesForFieldsAndMethods() line: 593
> CompilationUnitScope.faultInTypes() line: 447
> Compiler.process(CompilationUnitDeclaration, int) line: 752
Turns out that getting a resource when it does not exist can be pretty
expensive if you're compiling rules inside a big application with a lot of
stuff on your classpath, and this approach ends up tying the compilation
time of rules to the classloaders' search space.
I was wondering if we could have a better way to distinguish types and
packages or at least a configurable way. The first things that come to my
mind would be caching, in the lines of what is done for class loading in
the org.drools.util.CompositeClassLoader. Or have two different
strategies/implementations for the findType and isPackage methods, one that
would assume that you respect java conventions and parse the string to say
if it's a package or a type and another that wouldn't assume anything and
use the getResourceAsStream as it's done today. Then, we could choose via
configuration which strategy to use.
Any other ideas? Any work already being done in this area?
Cheers,
Leo.
12 years, 5 months
Support for Named Windows and new window types
by Edson Tirelli
Hi all,
I started working on the implementation of the new named windows feature
as well as the support to new window types. The goal of this work, besides
the support for the new feature is to overcome some of the limitations that
we had with the previous implementation.
I tried to write a quick overview of these ideas in the comments of the
JIRA I will use for this work:
https://issues.jboss.org/browse/JBRULES-2623
Feedback welcome.
Edson
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
12 years, 5 months
