[jboss-jira] [JBoss JIRA] (DROOLS-3448) kie-server-integ-tests-policy: Maven plugin loads spurious resources, classes from the classpath

[Mario Fusco (Jira)]

     [ https://issues.jboss.org/browse/DROOLS-3448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-3448:
-----------------------------------

    Assignee: Massimiliano Dessi  (was: Mario Fusco)


> kie-server-integ-tests-policy: 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: 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)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)