[JBoss JIRA] (DROOLS-3448) kie-server-integ-tests-policy: Maven plugin loads spurious resources, classes from the classpath
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-3448?page=com.atlassian.jira.plugi... ]
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)
5 years, 5 months
[JBoss JIRA] (DROOLS-3448) kie-server-integ-tests-policy: Maven plugin loads spurious resources, classes from the classpath
by Edoardo Vacchi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3448?page=com.atlassian.jira.plugi... ]
Edoardo Vacchi updated DROOLS-3448:
-----------------------------------
Description:
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)
was:
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)
> 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: Mario Fusco
> 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)
5 years, 5 months
[JBoss JIRA] (DROOLS-3448) kie-server-integ-tests-policy: Maven plugin loads spurious resources, classes from the classpath
by Edoardo Vacchi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3448?page=com.atlassian.jira.plugi... ]
Edoardo Vacchi updated DROOLS-3448:
-----------------------------------
Summary: kie-server-integ-tests-policy: Maven plugin loads spurious resources, classes from the classpath (was: Integration Tests: Maven plugin loads spurious resources, classes from the classpath)
> 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: 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)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (DROOLS-3448) Integration Tests: Maven plugin loads spurious resources, classes from the classpath
by Edoardo Vacchi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3448?page=com.atlassian.jira.plugi... ]
Edoardo Vacchi updated DROOLS-3448:
-----------------------------------
Summary: Integration Tests: Maven plugin loads spurious resources, classes from the classpath (was: Maven plugin loads spurious resources, classes from the classpath in full downstream build)
> 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)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (DROOLS-3448) Integration Tests: Maven plugin loads spurious resources, classes from the classpath
by Edoardo Vacchi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3448?page=com.atlassian.jira.plugi... ]
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)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (DROOLS-3448) Maven plugin loads spurious resources, classes from the classpath in full downstream build
by Edoardo Vacchi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3448?page=com.atlassian.jira.plugi... ]
Edoardo Vacchi updated DROOLS-3448:
-----------------------------------
Description:
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)
was:
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)
> Maven plugin loads spurious resources, classes from the classpath in full downstream build
> ------------------------------------------------------------------------------------------
>
> 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)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (DROOLS-3448) Maven plugin loads spurious resources, classes from the classpath in full downstream build
by Edoardo Vacchi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3448?page=com.atlassian.jira.plugi... ]
Edoardo Vacchi commented on DROOLS-3448:
----------------------------------------
this has been worked around with this patch https://github.com/kiegroup/droolsjbpm-integration/pull/1675
THIS IS NOT A FIX!
> Maven plugin loads spurious resources, classes from the classpath in full downstream build
> ------------------------------------------------------------------------------------------
>
> 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)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (DROOLS-3448) Maven plugin loads spurious resources, classes from the classpath in full downstream build
by Edoardo Vacchi (Jira)
Edoardo Vacchi created DROOLS-3448:
--------------------------------------
Summary: Maven plugin loads spurious resources, classes from the classpath in full downstream build
Key: DROOLS-3448
URL: https://issues.jboss.org/browse/DROOLS-3448
Project: Drools
Issue Type: Bug
Reporter: Edoardo Vacchi
Assignee: Mario Fusco
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)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months