Created attachment 738552 [details] server.log with deployment error Description of problem: Injection of KIE module through CDI fails on JBoss EAP 6.0/6.1 due to wrong processing of resource URI when loading pom.properties in ClasspathKieProject. Version-Release number of selected component (if applicable): BRMS 6.0.0.Beta1 EAP 6.0, 6.1.ER4 How reproducible: Deploy the attached reproducer WAR. Deployment fails, server.log contains the following error (see attachment for all errors in log): 15:40:29,923 INFO [stdout] (MSC service thread 1-2) kmodules: vfs:/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar/META-INF/kmodule.xml 15:40:29,939 ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-2) Unable to load pom.properties from/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar as jarPath cannot be found /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar The first log line shows that ClasspathKieProject located kmodule.xml at URL starting with protocol 'vfs:'. Later, in method fixURLFromKProjectPath, the protocol prefix is removed, leading to URL /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar which now references absolute path which is wrong. Steps to Reproduce: 1. Deploy attached reproducer WAR on EAP 6. 2. Watch server.log for deployment errors. Actual results: Deployment fails due to failed injection. Expected results: Application deploys successfully and writes INFO message into server.log. Additional info: This issue blocks further testing if KIE module injection through CDI. It also renders the CDI feature unusable in real environment (e.g. some web or EJB container with CDI).
Created attachment 738553 [details] Maven project with reproducer WAR Attached reproducer WAR which fails to deploy.
Comment on attachment 738553 [details] Maven project with reproducer WAR Maven project building reproducer WAR.
I have uploaded maven project containing two modules: - kie-module -- jar containing kmodule.xml, pom.properties and drl resources - web-app -- the actual reproducer war (In reply to comment #2) > Comment on attachment 738553 [details] > Maven project with reproducer WAR > > Maven project building reproducer WAR.
I have investigated this issue a little bit and I am sharing my thoughts: 1. the main problem is that org.drools.compiler.kie.builder.impl.ClasspathKieProject accesses classpath resources (identified by java.net.URL) using java.io.File. This does not work in case of JBoss AS deployment, since it uses JBoss VFS for deployments (URL of deployed classpath resource uses 'vfs:' protocol). 2. I have tried to change ClasspathKieProject#fixURLFromKProjectPath() not to remove the vfs protocol and return valid url which could load the resource from VFS. However, this is not enough, because attempting to create a File from the resource URL (new java.io.File(resourceUrl.toURI())) fails since java.io.File's constructor requires the URI to contain 'file:' protocol (or null). 3. Changing the ClasspathKieProject to work with resources by using URL instead of File would require changes to other classes: a. adding a new variant of KieBuilderImpl.findPomProperties(), probably taking URL(?) as an argument; this is quite a problem though, as the logic in findPomProperties (recursively looking for pom.properties in all subdirectories) cannot be (afaik) reasonably implemented with URL - it is not possible to list all subresources of a given URL, b. ZipKieModule and FileKieModule require a File to work with; probably a ClasspathKieModule class could be implemented that would work with classpath resources. Looking at FileKieModule implementation, I can see potential problems when implementing ClasspathKieModule in the methods getFile() and getFileNames() (at least their implementation is not straightforward to me at the moment). I have prepared a unit test for ClasspathKieProject.fixURLFromKProjectPath(), however, it might not be relevant if you decide to switch from File to URL. If you could still use the test, let me know and I will attach it.
thanks for looking into this more. We choice file instead of getResources, because we want full jar isolation when doing inspection. We followed weld-se discovery mechanisms for this. I'll try and find out what Weld does for AS, and try and follow that.
Mario Fusco <mario.fusco> updated the status of jira DROOLS-140 to Resolved
I have tested the fix on Drools 6.0.0.Beta3 and the reproducer war still fails to deploy: 16:57:25,608 INFO [stdout] (MSC service thread 1-7) kmodules: vfs:/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar/META-INF/kmodule.xml 16:57:25,680 WARN [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Unable to load pom.properties tried recursing down from/home/mwinkler/QA/jenkins/WORKSPACE/jboss-eap-6.1/standalone/tmp/vfs/deploymentb4fd41fdc21cc66f/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar-cecb296b30695181/contents null 16:57:25,680 ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Unable to build index of kmodule.xml url=vfs:/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar/META-INF/kmodule.xml null 16:57:25,710 ERROR [org.drools.compiler.cdi.KieCDIExtension] (MSC service thread 1-7) Annotation @KSession(basicKSession) found, but no KieSessioneModel exist. Either the required kproject.xml does not exist, was corrupted, or mising the KieBase entry It seems the problem is related to reading pom.properties from jar files which are distributed as libraries in a war (as it is the case in the attached reproducer). The pom.properties file is not unpacked in the deployment directory, it is a part of a jar file in WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar. The problem with vfs has been solved - the CDI works in case the kmodule is defined in the war file directly.
Created attachment 757721 [details] Maven project with reproducer WAR updated to Beta3 Updated reproducer maven project to Drools 6.0.0.Beta3 and fixed typo in KieSession name.
Fixed in CR1
*** Bug 995470 has been marked as a duplicate of this bug. ***
Verified on BRMS 6.0.0 ER2.
Hi Marek, Can you please share some more info on this bug, probably the fix and the result.
(In reply to Kanchan Desai from comment #15) > Hi Marek, > > Can you please share some more info on this bug, probably the fix and the > result. Hi Kanchan, in general, this issue has been caused by Drools resource loading which was not suitable for the JBoss EAP application server environment. EAP uses JBoss VFS and Drools resource loading mechanism had problems with that. The reason was that Drools attempts to locate every KieModule on the classpath by looking for all resources called 'META-INF/kmodule.xml'. For every such resource found, it needs also to locate pom.properties (or pom.xml) file. The problem was that path of pom.properties is not known in advance (it is located in a relative path to kmodule.xml, such as 'maven/<groupId>/<artifactId>/pom.properties'), where <groupId> and <artifactId> are directories named according to the maven artifact they are part of, therefore you cannot use standard java resource loading mechanism to locate it. Drools accessed the filesystem (either a jar, or physical filesystem) hosting the kmodule.xml resource to determine the location of pom.properties, which did not work in case of JBoss VFS. Mario has fixed that, in case you needed more technical details about the fix, he would give you the most accurate information. The result is working CDI injection of Drools KieBase and KieSession with EAP. The attached reproducer web app works now when deployed to EAP (it defines a CDI bean which is able to inject a KieSession defined in kmodule.xml).
Hi Marek, Doc Text has been added. Can you please review the CCFR.
Hi Kanchan, I propose the following changes to the doc text: Cause: The KIE module injection through CDI did not work in container as the new Drools resource loading mechanism was incompatible with the JBoss EAP application server environment which uses the JBoss VFS. Consequence: Drools was unable to load the KieModule on the web application classpath as the KieModule's pom.properties file could not be located by Drools resource loading mechanism when using JBoss VFS. Fix: The Drools resource loading mechanism has been updated to handle VFS resources correctly. Result: CDI injection of Drools KieBase and KieSession with EAP is now working.