[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-627:
-----------------------------------
[~manovotn] Yes, that's pretty much it. In CDI 1.0 the check was *intentionally* on the Class. Of course in CDI 1.0 it was not possible to add custom beans which return isAlternative()==true. Otoh if you already have an Extension then it's also really easy to veto the original bean to prevent AmbiguousResolutionExceptions.
I now like to allow both cases.
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-628:
----------------------------------------
Looks like breaking CDI concept to me (loose coupling since you need to know what you inject handling the scope at that level) and already doable through an extension so not sure it should be a core feature or a feature flipping library
> 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)
7 years, 9 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-627:
------------------------------------------
[~tremes] Do we have related test in TCK in 1.0 and did it changed in 1.1?
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-627:
-------------------------------------
Fix Version/s: 2.0 (proposed)
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point
by Stephan Knitelius (JIRA)
[ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.sy... ]
Stephan Knitelius updated CDI-628:
----------------------------------
Priority: Minor (was: Optional)
> 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)
7 years, 9 months
[JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point
by Stephan Knitelius (JIRA)
Stephan Knitelius created CDI-628:
-------------------------------------
Summary: 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: Optional
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)
7 years, 9 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-627:
-----------------------------------
To clarify, the deal is the following (please correct me if I am wrong [~struberg]):
* *In CDI 1.0* -> If there is *<NO CLASS>* with the specified name, or if the class with the specified name is not an alternative bean class, the container automatically detects the problem and treats it as a deployment problem.
* *Current state of spec* -> If there is *<NO BEAN>* whose bean class has the specified name, or if no bean whose bean class has the specified name is an alternative, the container automatically detects the problem and treats it as a deployment problem.
So basically by Vetoing the alternative (or excluding) it does not become a bean, hence the {{beans.xml}} will be considered invalid.
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Mark Struberg (JIRA)
Mark Struberg created CDI-627:
---------------------------------
Summary: fix wording regression for beans.xml alternative check introduced in 1.2
Key: CDI-627
URL: https://issues.jboss.org/browse/CDI-627
Project: CDI Specification Issues
Issue Type: Bug
Components: Concepts
Affects Versions: 1.2.Final
Reporter: Mark Struberg
My scenario is the following:
I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
{code}
@Alternative
@ApplicationScoped
@Exclude(ifProjectStage=Production.class)
public class MockMailService implements MailService {...}
{code}
Of course I only need to activate it in beans.xml:
{code}
<beans>
<alternatives>
<class>org.acme.MockMailService</class>
</alternatives>
</beans>
{code}
This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
What the intention was: all is fine IF one of
* There exists a class T with the given name
* That class T (or a contained producer field or producer method) is annotated with @Alternative
* There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months
[JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-471:
----------------------------------
[~meetoblivion] The set of qualifiers of the producer method {{producerTemplate()}} from the description above should just contain both {{@ContextName("ctx1")}} and {{@ContextName("ctx2")}}. So all the following injection points should resolve to the producer method as the bean has all the required qualifiers: {{@Inject @ContextName("ctx1") ProducerTemplate}}, {{@Inject @ContextName("ctx2") ProducerTemplate}} , {{@Inject @ContextName("ctx1") @ContextName("ctx2") ProducerTemplate}}.
> Support repeating qualifiers in typesafe resolution mechanism
> -------------------------------------------------------------
>
> Key: CDI-471
> URL: https://issues.jboss.org/browse/CDI-471
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Reporter: Antonin Stefanutti
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repea...], it would be valuable to percolate that support into the CDI typesafe resolution mechanism.
> For example, one could write:
> {code}
> @Qualifier
> @Repeatable(ContextNames.class)
> public interface @ContextName {
> String value;
> }
> public @interface ContextNames {
> ContextName[] value();
> }
> {code}
> And then:
> {code}
> @ContextName("ctx1")
> class CamelContext1 {
> }
> @ContextName("ctx2")
> class CamelContext2 {
> }
> @Uri("")
> @Produces
> @ContextName("ctx1")
> @ContextName("ctx2")
> static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance<CamelContext> instance) {
> }
> {code}
> That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies.
> Support of the annotation container / list for backward compatibility could be provided as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 9 months