kie-server-integ-tests-policy: Maven plugin loads spurious resources, classes from the classpath ------------------------------------------------------------------------------------------------ Key: DROOLS-3448 URL: https://issues.redhat.com/browse/DROOLS-3448 Project: Drools Issue Type: Bug Reporter: Edoardo Vacchi Assignee: Massimiliano Dessi Priority: Major Labels: drools-core Found out about this bug today, while trying to fix a full downstream build. A test in {{kie-server-integ-tests-policy}}, {{KieServerPolicyDroolsIntegrationTest}}, broke with a {{ClassCastException}}. The cast however should have been legal. h3.*tl;dr:* there is a class loading problem with {{kie-server-integ-tests-policy}} because of the way the Maven plugin is used there. h3. Suggested solution {{KieServerPolicyDroolsIntegrationTest}} instantiates a {{MavenCli}} object, but (apparently) the classpath is inherited by the test runner, causing classloading issues (detailed later). We should probably fork a new JVM with a fresh classpath, limited to the dependencies of the Maven plugin so that spurious classes are not on the classpath of the test. h3. Other details 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)