[
https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.sy...
]
Matej Novotny commented on CDI-628:
-----------------------------------
The current solution you mentioned with qualifiers doesn't actually do the same thing.
By creating two classes with different qualifiers you also creates two new bean _types_
along with it. And each of those new types will/can have a different scope.
While the feature you suggests says that the very same bean could have more scopes.
-1 for this, also Martin is right on the passivation topic.
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)