-
Bug
-
Resolution: Done
-
Major
-
None
-
None
ModuleSpecification keeps a lazy-loaded 'addDependencies' list, which is meant cache a compete set of dependencies to return from getAllDependencies. Any of the ModuleSpecification methods that update the various dependency collections null this out so it gets recreated with fresh data if getAllDependencies is called again. Except the addSystemDependency method, whjch does not null out the cache, leaving it incomplete if it exists.
This was causing unexplained behavior in my mvc-krazo extension development as the modules I was adding as system dependencies were not visible to
ServletContainerInitializerDeploymentProcessor, which calls getAllDependencies.
This goes all the way back to 2011, so caution is needed re possible side effects, e.g. code inadvertently relying on this behavior.
https://github.com/wildfly/wildfly-core/commit/b893ac286d2ae098794dbb385cd5222d4edf805a
Here are the current uses of getAllDependencies that would be affected by correcting this. Fortunately not too many:
Method
getAllDependencies()
Usages or usages of base method in Project and Libraries (6 usages found)
Unclassified (6 usages found)
wildfly-jaxrs (1 usage found)
org.jboss.as.jaxrs.deployment (1 usage found)
JaxrsIntegrationProcessor (1 usage found)
deploy(DeploymentPhaseContext) (1 usage found)
148 for (ModuleDependency dep : moduleSpec.getAllDependencies()) {
wildfly-undertow (1 usage found)
org.wildfly.extension.undertow.deployment (1 usage found)
ServletContainerInitializerDeploymentProcessor (1 usage found)
deploy(DeploymentPhaseContext) (1 usage found)
109 for (ModuleDependency dependency : moduleSpecification.getAllDependencies()) {
Maven: org.wildfly.core:wildfly-server:21.1.0.Final (4 usages found)
org.jboss.as.server.deployment.annotation (1 usage found)
CompositeIndexProcessor (1 usage found)
buildSubdeploymentDependencyMap(DeploymentUnit) (1 usage found)
171 for (ModuleDependency dep: deploymentUnit.getAttachment(Attachments.MODULE_SPECIFICATION).getAllDependencies()) {
org.jboss.as.server.deployment.module (3 usages found)
DeploymentVisibilityProcessor (1 usage found)
deploy(DeploymentPhaseContext) (1 usage found)
51 for (final ModuleDependency dependency : moduleSpec.getAllDependencies()) {
ModuleSpecProcessor (2 usages found)
createModuleService(DeploymentPhaseContext, DeploymentUnit, List<ResourceRoot>, List<ResourceRoot>, ModuleSpecification, ModuleIdentifier) (1 usage found)
280 ModuleDefinition moduleDefinition = new ModuleDefinition(moduleIdentifier, new HashSet<>(moduleSpecification.getAllDependencies()), moduleSpec);
installAliases(ModuleSpecification, ModuleIdentifier, DeploymentUnit, DeploymentPhaseContext) (1 usage found)
302 HashSet<ModuleDependency> dependencies = new HashSet<>(moduleSpecification.getAllDependencies());
Note that this problem might go undetected if some other DUP calls a method that nulls out the cache at some point between the addSystemDependency and getAllDependencies calls. I suspect that's why it hasn't been detected before. I'm testing a server config with a fairly small set of extensions.
- is related to
-
WFCORE-6606 WildFly main is failing some of Jakarta EE 10 Platform TCK Connector tests that depend on appclient deploying an ear with resource archive deployment dependencies
-
- Resolved
-
