[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-627:
---------------------------------
[~antoinesabot-durand] No there is no such test in TCK 1.0 which would assert that application is deployable with listed alternative which was vetoed/excluded in extension.
[~struberg] How it can become a 'candidate' when it's not annotated @Alternative or it's just vetoed? It's just not possible IMO.
bq. So either it originally was an @Alternative, ..
There is no such term or condition. Either it is an alternative or not.
> 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 John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-628:
--------------------------------
It is possible to create a bean via a portable extension that has two different scopes - two different beans. The JMS spec leverages this to allow JMSContext to be injectable for both request scoped and transaction scoped.
I would recommend that approach over the injection point overriding the scope.
> 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-471) Support repeating qualifiers in typesafe resolution mechanism
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.sy... ]
John Ament edited comment on CDI-471 at 9/8/16 6:28 AM:
--------------------------------------------------------
Ok, then we need to make sure the spec wording states that they behave like any other qualifier. Meaning if I had the following producers:
{code}
@Produces @ContextName("ctx1") ProducerTemplate pt1;
@Produces @ContextName("ctx2") ProducerTemplate pt2;
{code}
And an injection point:
{code}
@inject
@ContextName("ctx1")
@ContextName("ctx2")
private ProducerTemplate pt;
{code}
I would get no beans satisfying..
likewise, if I had the following producers:
{code}
@Produces @ContextName("ctx1") ProducerTemplate pt1;
@Produces @ContextName("ctx2") ProducerTemplate pt2;
@Produces @ContextName("ctx1") @ContextName("ctx2") ProducerTemplate pt;
{code}
and injection points:
{code}
@inject
@ContextName("ctx1")
@ContextName("ctx2")
private ProducerTemplate pt0;
@inject
@ContextName("ctx1")
private ProducerTemplate pt1;
@inject
@ContextName("ctx2")
private ProducerTemplate pt2;
{code}
The first injection point would work fine, however the second and third would give an ambiguous bean resolution, as behaves today.
was (Author: meetoblivion):
Ok, then we need to make sure the spec wording states that they behavior like any other qualifier. Meaning if I had the following producers:
{code}
@Produces @ContextName("ctx1") ProducerTemplate pt1;
@Produces @ContextName("ctx2") ProducerTemplate pt2;
{code}
And an injection point:
{code}
@inject
@ContextName("ctx1")
@ContextName("ctx2")
private ProducerTemplate pt;
{code}
I would get no beans satisfying..
likewise, if I had the following producers:
{code}
@Produces @ContextName("ctx1") ProducerTemplate pt1;
@Produces @ContextName("ctx2") ProducerTemplate pt2;
@Produces @ContextName("ctx1") @ContextName("ctx2") ProducerTemplate pt;
{code}
and injection points:
{code}
@inject
@ContextName("ctx1")
@ContextName("ctx2")
private ProducerTemplate pt0;
@inject
@ContextName("ctx1")
private ProducerTemplate pt1;
@inject
@ContextName("ctx2")
private ProducerTemplate pt2;
{code}
The first injection point would work fine, however the second and third would give an ambiguous bean resolution, as behaves today.
> 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
[JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-471:
--------------------------------
Ok, then we need to make sure the spec wording states that they behavior like any other qualifier. Meaning if I had the following producers:
{code}
@Produces @ContextName("ctx1") ProducerTemplate pt1;
@Produces @ContextName("ctx2") ProducerTemplate pt2;
{code}
And an injection point:
{code}
@inject
@ContextName("ctx1")
@ContextName("ctx2")
private ProducerTemplate pt;
{code}
I would get no beans satisfying..
likewise, if I had the following producers:
{code}
@Produces @ContextName("ctx1") ProducerTemplate pt1;
@Produces @ContextName("ctx2") ProducerTemplate pt2;
@Produces @ContextName("ctx1") @ContextName("ctx2") ProducerTemplate pt;
{code}
and injection points:
{code}
@inject
@ContextName("ctx1")
@ContextName("ctx2")
private ProducerTemplate pt0;
@inject
@ContextName("ctx1")
private ProducerTemplate pt1;
@inject
@ContextName("ctx2")
private ProducerTemplate pt2;
{code}
The first injection point would work fine, however the second and third would give an ambiguous bean resolution, as behaves today.
> 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
[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:
-----------------------------------
No Martin, I think in that case we miss if people ass <class>java.lang.Object</class>
It really needs to be a 'candidate' to be an @Alternative at least imo.
So either it originally was an @Alternative, or it gets made to one via Extensions. Enlisting other classes should imo fail.
> 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 Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-627:
----------------------------------
{quote}
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
{quote}
Hm, then the only requirement is _"a class with the given name must be on the classpath"_. Because if *it is*, the following items are irrelevant and if *it's not* the following requirements cannot be fullfilled.
> 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 commented on CDI-628:
---------------------------------------
[~manovotn] it is just meant to show that there is a possible work around :)
As stated, I am not really for it, I just wanted to spit ball the idea.
> 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 Matej Novotny (JIRA)
[ 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)
7 years, 9 months
[JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-628:
----------------------------------
-1 Not only this could break a lot of things but also redefines the concept of a bean, i.e. a bean has a single scope. Also imagine scenarios like {{@Inject @SessionScoped}} for a bean which originally has a non-passivating scope and similar...
> 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)
[ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.sy... ]
Stephan Knitelius commented on CDI-628:
---------------------------------------
[~rmannibucau] agree with you on that. Just a bit unsure, so I put it out there to spit ball the idea.
> 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