Uploaded image for project: 'WildFly Core'
  1. WildFly Core
  2. WFCORE-6601

ModuleSpecification.setSystemDependency does not reset the allDependencies list




      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.


      Here are the current uses of getAllDependencies that would be affected by correcting this. Fortunately not too many:

      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.


        Issue Links



              bstansbe@redhat.com Brian Stansberry
              bstansbe@redhat.com Brian Stansberry
              0 Vote for this issue
              2 Start watching this issue