[weld-issues] [JBoss JIRA] Issue Comment Edited: (WELD-973) @Specializes is not compatible with seam-config because of a problem in weld's BeanDeployerEnvironment

[Geoffrey De Smet (JIRA)]

    [ https://issues.jboss.org/browse/WELD-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628085#comment-12628085 ] 

Geoffrey De Smet edited comment on WELD-973 at 9/13/11 6:41 AM:
----------------------------------------------------------------

Note the far-reaching effect of this issue:
*Any bean that is specialized by or specializes another bean cannot be configured by seam-config.*
If @Specializes is used and 1 of the 2 involved beans is seam-configured, weld crashes always (even if the subclass is an @Alternative).

      was (Author: ge0ffrey):
    Note the far-reaching effect of this issue:
*Any bean that is specialized by or specializes another bean cannot be configured by seam-config.*
If @Specializes is used and 1 of the 2 involved beans in configured, weld crashes always (even if the subclass is an @Alternative).
  
> @Specializes is not compatible with seam-config because of a problem in weld's BeanDeployerEnvironment
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WELD-973
>                 URL: https://issues.jboss.org/browse/WELD-973
>             Project: Weld
>          Issue Type: Bug
>    Affects Versions: 1.1.2.Final
>            Reporter: Geoffrey De Smet
>
> BeanDeployerEnvironment has 2 methods which - combined with seam-config - break @Specializes:
> {code}
> public class BeanDeployerEnvironment {
>    private final Map<WeldClass<?>, AbstractClassBean<?>> classBeanMap;
>    protected void addAbstractClassBean(AbstractClassBean<?> bean)
>    {
>       ...
>          classBeanMap.put(bean.getWeldAnnotated(), bean);
>       ...
>    }
>    public AbstractClassBean<?> getClassBean(WeldClass<?> clazz)
>    {
>       if (!classBeanMap.containsKey(clazz))
>       {
>          return null;
>       }
>       ...
>    }
> {code}
> Here's what happens:
> In this use case I have a bean RepositoryStartupService, which is extra configured by seam-config.
> It is also specialized by TestRepositoryStartupService (for tests).
> 1) First addAbstractClassBean is called with these parameters:
> {code}
> bean = Managed Bean [class org.drools.guvnor.server.repository.RepositoryStartupService] with qualifiers [@Any @Default @Named]
> bean.bean.getWeldAnnotated() = public at Named @XmlConfiguredBean @ApplicationScoped @XmlId class org.drools.guvnor.server.repository.RepositoryStartupService
> {code}
> 2) Later on, getClassBean is called to find the parent class RepositoryStartupService:
> {code}
> clazz = public at Named @ApplicationScoped class org.drools.guvnor.server.repository.RepositoryStartupService
> {code}
> which returns null because the @XmlConfiguredBean bits are missing.
> So I get this exception message:
> {code}
> org.jboss.weld.exceptions.DefinitionException: WELD-000047 Specializing bean must extend another bean:  Managed Bean [class org.drools.guvnor.server.repository.TestRepositoryStartupService] with qualifiers [@Any @Default]
> {code}
> One can argue that since seam-config is not configuring TestRepositoryStartupService a failure is normal,
> but *even in that case the exception message is very misleading*, as looking at the code TestRepositoryStartupService clearly extends RepositoryStartupService which is also a bean.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira