[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-627:
---------------------------------
I prefer to clearly list the conditions for the DefintionException. It also matches other DefinitionException style. However, the following sentence is not well spelt out.
* the class is not annotated with @Alternative AND the class is not a bean class of a Bean<T> with isAlternative() == true
I would suggest to stay similar to CDI 1.0 but change to the following or something similar
If there is no class with the specified name, or if the class with the specified name is not an alternative bean class and no corresponding custom alternative bean class is defined, the container automatically detects the problem and treats it as a deployment problem.
By the way, although we are fixing back cdi 1.2 to cdi 1.0, we are potentially introducing a backward incompatibility with cdi 1.2 spec. Any concerns?
> 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, 7 months
[JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-625:
---------------------------------
+1 on creating a new event. The previous event did what it said though:). I think it correctly interpreted the meaning of Destroyed thought it is not useful. Perhaps the new event can be called @PreDestroying(X.class)
> 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, 7 months
[JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-625:
-----------------------------------
For all but @ApplicationScoped it's not really a problem.
And for that we could introduce another new event probably?
> 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, 7 months
[JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-625:
----------------------------------------
CDI provided literals are not yet mainstream and custom impl are still regularly seens so the breaking bck compat is a real concern IMO
if interceptor approach is not liked we have to just define what we do I think. Not firing an event before makes sense since a bean with a @PreDestroy can always replace it (@Obserse init to init the bean then predestroy will be the before end event)
> 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, 7 months
[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 commented on CDI-625:
----------------------------------
[~rmannibucau] I see, you're right that existing literals would be broken. On the other hand, CDI API now provides its own literals which could be used instead. Also these literals are used mostly by CDI container itself. Rarely by extensions firing events for custom contexts and custom observer methods...
-1 for "interceptor" approach. Looks unnecessarily complex.
> 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, 7 months
[JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-625:
-----------------------------------
Hmm that really sounds like we should fire another event _before_ destroying.
I don't like the interceptor way. Adds too much overhead I fear.
> 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, 7 months
[JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-625:
----------------------------------------
not if you add it programmatically (new DestroyedLiteral(....))
> 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, 7 months
[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 commented on CDI-625:
----------------------------------
[~rmannibucau] What "SPI API"? Adding a member with a default value to an annotation should be backward compatible.
> 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, 7 months
[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 commented on CDI-625:
----------------------------------
As I already said above... _both OWB and Weld interpreted this (mostly) as "fire after destruction"_ (see also WELD-2229).
> 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, 7 months
[JBoss JIRA] (CDI-625) When exactly are events with @Initialized(X.class) and @Destroyed(X.class) qualifiers fired
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-625:
----------------------------------------
[~martinkouba] beforePhase would need another flag in the SPI API and therefore could break existing applications.
[~tremes] ctx.proceed() would go to the next observer until the final invocation like interceptor chain. Since observers can be sorted with @Priority there is no big deal there. About compatibility since EventContext would be new we can say this is part of CDI bus and this is not a type you can fire directly without breaking anything.
> 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, 7 months