[cdi-dev] [JBoss JIRA] Commented: (CDI-112) Clarify how alternatives are enabled

[Mark Struberg (JIRA)]

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

Mark Struberg commented on CDI-112:
-----------------------------------

Imo an <alternative> should be enabled for the whole 'slice' of classes the BeanManager works for. See CDI-18. This is essential because in practice you cannot _repack_ all you jars just to enable an alternative YyyService in those jars. The <first> <others> turned out to be not flexible enough for lots of situations. Thus I prefer an ordinal with a float value.

> Clarify how alternatives are enabled
> ------------------------------------
>
>                 Key: CDI-112
>                 URL: https://issues.jboss.org/browse/CDI-112
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Beans
>    Affects Versions: 1.0
>            Reporter: Shane Bryzak
>             Fix For: 1.1 (Proposed)
>
>
> The spec is open to interpretation about how alternatives are enabled.  One popular interpretation is that alternatives must be enabled within the same bean archive that contains the alternative bean.  However, it might be worth considering the merit of enabling an alternative from a deployment archive that contains the bean archive.  
> For example, suppose we have the following deployment archive:
> foo.war
>   /WEB-INF
>     beans.xml
>   /lib
>     bar.jar
>       /META-INF
>         beans.xml
>       /com
>         /acme
>           AlternativeBean.class
> It may be worth allowing AlternativeBean.class (a class annotated with @Alternative) to be enabled by listing it in the <alternatives> section of foo.war/WEB-INF/beans.xml.

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