-
Bug
-
Resolution: Duplicate
-
Major
-
None
-
1.5.1.Final
-
None
-
None
I have a deployment where a subdeployment is dependent on another subdeployment, referencing it via alias:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1"> <ear-subdeployments-isolated>true</ear-subdeployments-isolated> <sub-deployment name="ejb1.jar"> <module-alias name="deployment.ejb1"/> </sub-deployment> <sub-deployment name="ejb2.jar"> <dependencies> <module name="deployment.ejb1" slot="main"/> </dependencies> </sub-deployment> </jboss-deployment-structure>
When deploying, modules are loaded and added to the ModuleLoader.moduleMap:
2016-05-31 16:19:55,195 TRACE [org.jboss.modules] (MSC service thread 1-1) Locally loading module deployment.test.ear:main from Service Module Loader 2016-05-31 16:19:55,200 TRACE [org.jboss.modules] (MSC service thread 1-3) Locally loading module deployment.test.ear.ejb1.jar:main from Service Module Loader 2016-05-31 16:19:55,200 TRACE [org.jboss.modules] (MSC service thread 1-5) Locally loading module deployment.test.ear.ejb2.jar:main from Service Module Loader 2016-05-31 16:19:55,204 TRACE [org.jboss.modules] (MSC service thread 1-5) Locally loading module deployment.ejb1:main from Service Module Loader
Note that moduleMap entries for "deployment.test.ear.ejb1.jar:main" and "deployment.ejb1:main" reference the same module instance, with module.identifier set to "deployment.test.ear.ejb1.jar:main".
When undeploying, ModuleSpecLoadListeners try to unload all four modules, however entry with key "deployment.ejb1:main" is not removed from moduleMap, because of how the unload method is implemented:
protected final void unloadModuleLocal(Module module) throws SecurityException { //... final ModuleIdentifier id = module.getIdentifier(); final FutureModule futureModule = moduleMap.get(id); if (futureModule != null && futureModule.module == module) { moduleMap.remove(id, futureModule); } }
(In this case module.identifier != entry key.)
This left-over entry then interferes with subsequent deployments, causing duplicate classes and consequently failed deployments (JBEAP-4650).
How should this situation be handled? Can all instances of given module always be removed from moduleMap?
- causes
-
JBEAP-4650 [GSS](7.0.z) Unsatisfied dependencies on hot deploy of app using module-alias as dependency
- Verified
-
WFLY-6636 WELD-001408: Unsatisfied dependencies on hot deploy of app using module-alias as dependency
- Open
- duplicates
-
MODULES-241 Leaked Alias Modules
- Resolved