[
https://issues.jboss.org/browse/CDI-407?page=com.atlassian.jira.plugin.sy...
]
Thomas Andraschko commented on CDI-407:
---------------------------------------
Don't know, maybe @Alternative isn't 100% the right thing for me.
I'm actually looking for way to 100% replace the parent bean but via config.
I have the following case:
public class DefaultNavigationController
@Specializes public class CustomerANavigationController extends
DefaultNavigationController
public class SpecialCustomerANavigationController extends CustomerANavigationController
SpecialCustomerANavigationController should be an alternative specialization of
CustomerANavigationController, which can be enabled for some tools.
Maybe something like this would be great:
@Speciales @Alternative
public class SpecialCustomerANavigationController extends CustomerANavigationController
If the bean is configures in the beans.xml, it should completely replace
CustomerANavigationController and DefaultNavigationController.
Maybe it's a special case but i have this case multiple times inside our product...
Specifiy @Named @Alternatives
-----------------------------
Key: CDI-407
URL:
https://issues.jboss.org/browse/CDI-407
Project: CDI Specification Issues
Issue Type: Clarification
Components: Beans, Inheritance and Specialization
Reporter: Thomas Andraschko
It's actually a must-have for product development and a common case.
We would like to have multiple implementations in our core and just activate them via
alternative.
I talked with struberg and its currently not defined in the specs.
e.g.
@Named public class A
@Named @Alternative public class B extends A
What should acutally happen if B is activated via beans.xml?
IMO B should be available in EL via "a" and "b".
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)