use correct vfs path 'contents'

[cherni78]

Since Wildfly 31.0.0 we encountered the following problem:

ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (EJB async-pool - 3) [Usr#] Unable to build index of kmodule.xml url=vfs:/.../wildfly-31.0.0.Final/standalone/deployments/.../META-INF/kmodule.xml
Unable to get all ZipFile entries: ...\wildfly-31.0.0.Final\standalone\tmp\vfs\deployment\deploymentedb670f3fadfd5b0\...\content



Caused by: java.lang.RuntimeException: Cannot find a default KieSession
	at deployment.BisonProcess.ear//org.drools.compiler.kie.builder.impl.KieContainerImpl.findKieSessionModel(KieContainerImpl.java:557)
	at deployment.BisonProcess.ear//org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:600)
	at deployment.BisonProcess.ear//org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:530)
	at deployment.BisonProcess.ear//org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:513)

Seems that the problem comes from the typo in the fixed typed vfs lookup path.
After changing it to 'contents' it works well!

[mariofusco]

Fixed by 72c1d6b

[cherni78]

I think it's not fixed.
Because here is still the wrong path with 'content' instead of 'contents'.

[reinhapa]

Fixed by 72c1d6b

@mariofusco we found that change in our currently used drools version 9.44.0, that does not work as intended and produces the exact stack as described in this issue...

[mariofusco]

This is not a simple typo (it worked with old wildfly) but the effect of a recent change in wildfly/eap as it has been reported here https://issues.redhat.com/browse/DROOLS-7608

@cherni78 @reinhapa I'd appreciate it if you could give a try to your reproducers using the commits that I linked and if it doesn't work I will investigate again the problem. But at the moment simply adding an 's' doesn't seem the right solution and however if I do so I will also break compatibility with wildfly versions < 31.0

[cherni78]

After a few more analyses @reinhapa and I found the problem with Wildfly 31.0.0.
It seems to be a ClassLoader-Problem. It happens in the method ImmutableRuleCompilationPhase.compileRulesLevel

The ContextClassLoader used within the ForkJoinPoolTask is not the same as within the compileRulesLevel method.
When passing the ClassLoader into the lambda everything works as expected.

The following patch worked:

diff --git a/drools-compiler/src/main/java/org/drools/compiler/builder/impl/processors/ImmutableRuleCompilationPhase.java b/drools-compiler/src/main/java/org/drools/compiler/builder/impl/processors/ImmutableRuleCompilationPhase.java
index ac94c80e78..9a8055b9ee 100644
--- a/drools-compiler/src/main/java/org/drools/compiler/builder/impl/processors/ImmutableRuleCompilationPhase.java
+++ b/drools-compiler/src/main/java/org/drools/compiler/builder/impl/processors/ImmutableRuleCompilationPhase.java
@@ -269,18 +269,25 @@ public class ImmutableRuleCompilationPhase extends AbstractPackageCompilationPha
         if (parallelRulesBuild) {
             Map<String, RuleBuildContext> ruleCxts = new ConcurrentHashMap<>();
             try {
+                final ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
                 KnowledgeBuilderImpl.ForkJoinPoolHolder.COMPILER_POOL.submit(() ->
                         rules.stream().parallel()
                                 .filter(ruleDescr -> filterAccepts(ResourceChange.Type.RULE, ruleDescr.getNamespace(), ruleDescr.getName()))
                                 .forEach(ruleDescr -> {
-                                    initRuleDescr(packageDescr, pkgRegistry, ruleDescr);
-                                    RuleBuildContext context = buildRuleBuilderContext(pkgRegistry, ruleDescr);
-                                    ruleCxts.put(ruleDescr.getName(), context);
-                                    List<? extends KnowledgeBuilderResult> results = addRule(context);
-                                    if (!results.isEmpty()) {
-                                        synchronized (this.results) {
-                                            this.results.addAll(results);
-                                        }
+                                    final ClassLoader savedCurrentClassLoader = Thread.currentThread().getContextClassLoader();
+                                    try {
+                                      Thread.currentThread().setContextClassLoader(contextClassLoader);
+                                      initRuleDescr(packageDescr, pkgRegistry, ruleDescr);
+                                      RuleBuildContext context = buildRuleBuilderContext(pkgRegistry, ruleDescr);
+                                      ruleCxts.put(ruleDescr.getName(), context);
+                                      List<? extends KnowledgeBuilderResult> results = addRule(context);
+                                      if (!results.isEmpty()) {
+                                          synchronized (this.results) {
+                                              this.results.addAll(results);
+                                          }
+                                      }
+                                    } finally {
+                                      Thread.currentThread().setContextClassLoader(savedCurrentClassLoader);
                                     }
                                 })
                 ).get();

[reinhapa]

@mariofusco seems that the current fix does still have some glitch when using a fork join pool.

[mariofusco]

@cherni78 @reinhapa I'm investigating this problem again, but still not able to reproduce it. Can you please provide a simple example reproducing thus issue, so we will be sure of being on the same page? Thanks.

[mariofusco]

I created a sample project using our current main branch, tested under WildFly Full 31.0.1.Final and it seems to work fine for me. In particular it is able to correctly retrieve the KieProject inside the classpath as reported by the log.

14:08:10,832 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (default task-1) Found kmodule: vfs:/content/rest-endpoint.war/WEB-INF/lib/drools-project-1.0-SNAPSHOT.jar/META-INF/kmodule.xml
14:08:10,834 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (default task-1) Virtual file physical path = /home/mario/software/wildfly-31.0.1.Final/standalone/tmp/vfs/temp/tempd4b311ff42b8e2fe/content-c070abcdbe655535/WEB-INF/lib/drools-project-1.0-SNAPSHOT.jar

Please modify the sample project that I'm providing (or feel free to send your reproducer) in case you still think that there is a problem.

[reinhapa]

I created a sample project using our current main branch, tested under WildFly Full 31.0.1.Final and it seems to work fine for me. In particular it is able to correctly retrieve the KieProject inside the classpath as reported by the log.

@mariofusco We will give it a try and come back to you...

[mareknovotny]

@reinhapa @cherni78 can you guys create then an issue here https://github.com/apache/incubator-kie-drools/issues to properly track it?