[jboss-jira] [JBoss JIRA] (WFLY-8656) Bean discovery in deployment dependencies (modules) is always interpreted as "all"

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-8656:
-----------------------------------
    Fix Version/s: 12.0.0.Alpha1


> Bean discovery in deployment dependencies (modules) is always interpreted as "all"
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-8656
>                 URL: https://issues.jboss.org/browse/WFLY-8656
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.1.0.Final, 11.0.0.Beta1
>            Reporter: Yoann Rodière
>            Assignee: Martin Kouba
>             Fix For: 12.0.0.Alpha1
>
>
> 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:
> {code}
> 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);
> {code}
> 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.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)