[JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-625:
-----------------------------
Description:
The spec states that {{(a)Initialized(X.class)}} is fired when a context is initialized and {{(a)Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_).
Does it mean that:
* {{(a)Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready?
* {{(a)Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed?
I'm asking because for {{(a)Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601.
In RI/Weld, the behaivour of {{(a)Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed.
I believe this should be more clear.
was:
The spec states that {{(a)Initialized(X.class)}} is fired when a context is initialized and {{(a)Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_).
Does it mean that:
* {{(a)Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready?
* {{(a)Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed?
I'm asking because for {{(a)Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601.
In RI/Weld, the behaivour of {{(a)Destroyed(X.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed.
I believe this should be more clear.
> When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
> -------------------------------------------------------------------------------------------
>
> Key: CDI-625
> URL: https://issues.jboss.org/browse/CDI-625
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Reporter: Martin Kouba
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> The spec states that {{(a)Initialized(X.class)}} is fired when a context is initialized and {{(a)Destroyed(X.class)}} when a context is destroyed (note that for {{@ApplicationScoped}} the wording leaves out the context: _"when the application is destroyed"_).
> Does it mean that:
> * {{(a)Initialized(X.class)}} is fired *after the initialization* of a context is finished, i.e. the context is ready?
> * {{(a)Destroyed(X.class)}} is fired *after the destruction* of a context is finished, i.e. after all the beans are destroyed?
> I'm asking because for {{(a)Destroyed(X.class)}} it might be useful to perform some cleanup before the context is actually destroyed - see also CDI-601.
> In RI/Weld, the behaivour of {{(a)Destroyed(ApplicationScoped.class)}} is currently a little bit inconsistent. For webapps and Weld SE, the event is fired before the context is destroyed. But for non-web EE modules (e.g. ejb jar) the event is fired after the context is destroyed.
> I believe this should be more clear.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
What to do to move CDI-30/PR 296 Forward
by John Ament
All,
It seems like we're still stuck on CDI-30. Its been open, last activity on Aug 2. I would love to see it closed and only reference the use case agreed to - another library wants to integrate CDI into its stack. To do so, it wants to be able to start and stop the built in contexts.
John
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
7 years, 8 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:
----------------------------------
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)
7 years, 8 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:
----------------------------------
Yes John, exactly!
> 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, 8 months
[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:
---------------------------------
[~struberg] Can you please provide link to the test when it passes?
> 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, 8 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 edited comment on CDI-628 at 9/8/16 6:37 AM:
---------------------------------------------------------------
[~meetoblivion] thanks for pointing that out.
I guess this can be rejected/closed. Hardly any benefit and a lot of very good points against it.
was (Author: sknitelius):
[~meetoblivion] thanks for pointing that out, pretty sure we have come to the conclusion that this is a bad 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, 8 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:
---------------------------------------
[~meetoblivion] thanks for pointing that out, pretty sure we have come to the conclusion that this is a bad 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, 8 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:
-----------------------------------
[~tremes] in my case it IS annotated with @Alternative. But it still blows up in the latest Weld version (Worked perfectly fine with Weld EE6 level).
> 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, 8 months
