ignore-dependency in jboss-web.xml does not work ------------------------------------------------ Key: WFLY-11282 URL: https://issues.jboss.org/browse/WFLY-11282 Project: WildFly Issue Type: Bug Affects Versions: 15.0.0.Alpha1 Environment: JBoss EAP 7.1.0 Java 8u192 CentOS 7.5 x64 Reporter: Jiri Ondrusek Assignee: Jiri Ondrusek Priority: Major Labels: deploy, deployment, resource-ref 1. Use of *ignore-dependency* in the *resource-ref* in *jboss-web.xml* doesn't work, the resource reference remains mandatory. Have the following in *web.xml* {code:xml}<resource-ref> <res-ref-name>wm/WM1</res-ref-name> <res-type>commonj.work.WorkManager</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref> <resource-ref> <res-ref-name>tm/TM1</res-ref-name> <res-type>commonj.timers.TimerManager</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Unshareable</res-sharing-scope> </resource-ref>{code} In order to let the ear/war deploy at JBoss EAP (where the CommonJ API isn't available), add a *jboss-web.xml* setting these resource references to be ignored by adding *<ignore-dependency/>* {code:xml}<?xml version="1.0" encoding="UTF-8"?> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_7_2.xsd" version="7.2"> <context-root>mod</context-root> <resource-ref> <res-ref-name>wm/WM1</res-ref-name> <jndi-name>DummyWorkManager</jndi-name> <ignore-dependency/> </resource-ref> <resource-ref> <res-ref-name>tm/TM1</res-ref-name> <jndi-name>DummyTimerManager</jndi-name> <ignore-dependency/> </resource-ref> </jboss-web>{code} However the deploy will fail (as if the jboss-web.xml wouldn't be there at all): {noformat}ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."APP.ear"."mod.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."APP.ear"."mod.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "mod.war" of deployment "APP.ear" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEE0027: Could not load commonj.work.WorkManager referenced in env-entry at org.jboss.as.ee.component.deployers.ResourceReferenceProcessor.getResourceRefEntries(ResourceReferenceProcessor.java:153) at org.jboss.as.ee.component.deployers.ResourceReferenceProcessor.processDescriptorEntries(ResourceReferenceProcessor.java:74) at org.jboss.as.ee.component.deployers.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:95) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) ... 5 more Caused by: java.lang.ClassNotFoundException: commonj.work.WorkManager from [Module "deployment.APP.ear.mod.war" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) at org.jboss.as.ee.component.deployers.ResourceReferenceProcessor.getResourceRefEntries(ResourceReferenceProcessor.java:151) ... 8 more{noformat} \\ 2. Overriding *resource-ref* from *web.xml* in *jboss-web*.xml doesn't work properly. I can partially work around the above ClassNotFoundException by adding a dummy res-type like {code:xml}<res-type>javax.resource.Referenceable</res-type>{code} to both resource references in jboss-web.xml, however this seems to override only the 1st entry as the ClassNotFoundException will change to {noformat}java.lang.ClassNotFoundException: commonj.timers.TimerManager{noformat} and I don't seem to be able to get rid of this one in any way, save for removing the 2nd resource reference (timer manager) from web.xml and jboss.xml completely. Then the deploy will fail with {noformat}ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "APP.ear")]) - failure description: { "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.module.app-name.mod-name.env.DummyWorkManager"], "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.app-name.mod-name.env.wm.WM1 is missing [jboss.naming.context.java.module.app-name.mod-name.env.DummyWorkManager]"] }{noformat} which only confirms that the ignore-dependency doesn't work. Notes: - The fact that the CommonJ API can't be used at JBoss EAP isn't a problem. The ear is built to be usable for multiple app servers. The CommonJ WorkManager and TimerManager resources are used only at those app servers where available. We just need the ear to successfully deploy at JBoss EAP. We can take care of the rest. - It's likely that providing a modified web.xml via deployment overlay would make things work (not tested but I'm pretty confident about that), but we want to avoid that, we'd like to have the ear deploy straight away (and it should be possible with the use of ignore-dependency) - ignore-dependency did work at JBoss AS 6.0, see https://developer.jboss.org/thread/160804 - Slightly more extensive description of both issues is available here: https://stackoverflow.com/questions/52967897/jboss-eap-7-1-how-to-ignore-... - Since there are actually 2 issues being reported here (but they seem to be connected), this JIRA issue can be split into 2 if required