[
https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.sy...
]
Martin Kouba commented on CDI-628:
----------------------------------
Just a note - JMS wording and solution/impl is IMHO also not correct from the CDI point of
view. Because, for the same IP you should get different beans depending on the TX status
and this is normally an ambiguous resolution, so they have to implement some kind of
delagation bean injected and forwarding the calls to either {{@RequestScoped}} or
{{@TransactionScoped}} implementation.
Allow overriding of Scope at Injection Point
--------------------------------------------
Key: CDI-628
URL:
https://issues.jboss.org/browse/CDI-628
Project: CDI Specification Issues
Issue Type: Feature Request
Affects Versions: 2.0 (proposed)
Reporter: Stephan Knitelius
Priority: Minor
Allow overriding scopes at injection point.
{code}
@SessionScope
public class FeatureState {...}
public class Bean B {
@Inject
@ConversationScoped //Overriding original scope
public BeanA beanA;
...
}
{code}
Sample use-case for for a feature flag:
{code}
@Alternative
public class FeatureStateProducer {
@Inject
@SessionScoped
private FeatureState devState;
@Inject
@ConversationScoped
private FeatureState viewState;
@Inject
private JNDIProvider jndiProvider;
private boolean viewOnly = true;
@PostConstruct
public void postConstruct() {
this.viewMode = ...; //read config.
}
@Produces
public FeatureState produce() {
return viewOnly ? viewState : devState;
}
}
{code}
Currently this can be solved by overriding scope with @Qualifiers:
{code}
@ViewMode
@ConversationScoped
public class ViewFeatureState extends FeatureState {...}
@DevMode
@SessionScoped
public class DevFeatureState extends FeatureState {...}
{code}
Risks:
* developers might start to define the scopes at IP and on bean (hard to maintain).
* confusing when debugging, annotation on bean, e.g. @ApplicationScoped yet behaving
differently.
* etc...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)