Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-8656

Bean discovery in deployment dependencies (modules) is always interpreted as "all"

XMLWordPrintable

      The CDI spec specifies that the beans.xml file may set the "bean discovery mode" for a given bean archive: https://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_archive
      Possible values include "all" (all classes should be considered as CDI beans) and "annotated" (only classes with class-level CDI annotations should b considered as CDI beans).

      In Wildfly, this bean discovery mode is taken into account correctly for deployments, but not for the modules they depend on. For those modules, provided there is a beans.xml, and irrespective of the bean discovery mode set inside this file, every single class is considered as a bean and added to the CDI context.


      This behavior is not related to the bean discovery mode defined in the "beans.xml" of the deployment. Actually, the code responsible for handling bean discovery in deployments and in their dependency is clearly separated. It seems that ExternalBeanArchiveProcessor is responsible for bean discovery in dependencies, and this class completely ignores the bean discovery mode defined in the bean.xml and always populate the archive with every single discovered class:

      final BeansXml beansXml = parseBeansXml(url, parser, deploymentUnit);
      
      final UrlScanner urlScanner = new UrlScanner();
      
      final List<String> discoveredClasses = new ArrayList<String>();
      if (!urlScanner.handleBeansXml(url, discoveredClasses)) {
          continue;
      }
      discoveredClasses.removeAll(componentClassNames);
      
      /*
       * Below, the archive is populated with every discovered class,
       * irrespective of beansXML.getBeanDiscoveryMode()
       */
      final BeanDeploymentArchiveImpl bda = new BeanDeploymentArchiveImpl(new HashSet<String>(discoveredClasses), beansXml, dependency, beanArchiveIdPrefix + url.toExternalForm(), BeanArchiveType.EXTERNAL);
      

      There seems to be hard-coded exceptions for jsf-impl-2.2 and resteasy-cdi, so I suspect this problem has been noticed before, but I couldn't find any open ticket.

              mkouba@redhat.com Martin Kouba
              rh-ee-yrodiere Yoann Rodière
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: