]
Edoardo Vacchi updated DROOLS-3448:
-----------------------------------
Steps to Reproduce:
pretty hard to reproduce. It occurs when a dependency is not declared in the pom.xml of
the maven plugin, but it is a runtime dependency of some other component.
However, the problem has never occurred because right now every Assembler lives in a jar
that is usually IN the Maven plugin dependencies!! the CMMN is an outlier, but in fact
this should (and most likely WILL) be the norm at some point!
was:
pretty hard to reproduce. It occurs when a dependency is not declared in the maven plugin,
but it is a runtime dependency of some other component.
However, the problem has never occurred because right now every Assembler lives in a jar
that is usually IN the Maven plugin dependencies!! the CMMN is an outlier, but in fact
this should (and most likely WILL) be the norm at some point!
Integration Tests: Maven plugin loads spurious resources, classes
from the classpath
------------------------------------------------------------------------------------
Key: DROOLS-3448
URL:
https://issues.jboss.org/browse/DROOLS-3448
Project: Drools
Issue Type: Bug
Reporter: Edoardo Vacchi
Assignee: Mario Fusco
Priority: Major
Labels: drools-core
Found out about this bug today, while trying to fix a full downstream build.
{{KieServerPolicyDroolsIntegrationTest}} broke with a ClassCastException.
*tl;dr: *there is a problem with ClassLoader delegates AND the way Service Discovery look
for {{kie.conf}} on the classpath.
As part of DROOLS-3355, DROOLS-3307 I have moved CMMN package-building phase to the
Assembler API. This highlighted an issue in the way the Maven plugin is tested (and/or the
Service discovery mechanism, depending on how you want to see it)
This is what I have understood:
- CMMNAssemblerService is in its own package, which depends on jBPM.
- the Maven plugin injects its own ClassLoader,
- then it calls {{KieServices.Factory.get()}},
- this causes the Service discovery to start, and all the services found in the
{{kie.conf}}s that are on the current classpath
Please notice that the classpath in the Full Downstream Build includes all the
packages, so every kie.conf found in every project jar
In the test that broke {{KieServerPolicyDroolsIntegrationTest}}:
- Maven instance is created; It is created a new class loader (@ BuildMojo#buildDrl()
) with the jars on which Maven plugin depends.
Before my fix, this *DID not* include the dependency on CMMN
- *however* kie.conf for CMMNAssemblerService is in the class path of full downstream
build!
- because it is not a direct Maven dependency, it is *not* in the class loader of the
Maven build
- CMMNAssemblerService is therefore loaded from the *root classloader*
- when KieAssemblerServices are processed, all assembler services *except CMMN* are
found in the maven classpath, so they are loaded from that class loader
- ClassCastException is raised when CMMNAssemblerService is used because it is not an
instance of KieAssemblerService (really, it is: but the class KieAssemblerService has now
been loaded from the maven class loader, while CMMNAssemblerService has been loaded from
the root classloader)
The problem is that the chain of classloaders AND the service discovery mechanism:
- The classloader delegates to the root classloader, which loads from the full downstream
classpath, which includes everything and loads a service that should not be found; this in
turn causes the ClassCastException
- the service discovery mechanism loads {{kie.conf}} from the full downstream classpath,
which includes jars that should not be processed (as they would not be in the maven plugin
classpath)