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

ModuleSpecification.setSystemDependency does not reset the allDependencies list

    XMLWordPrintable

Details

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: