[JBoss JIRA] (CDI-629) Consider standardizing AnnotationInstaceProvider from DeltaSpike
by Martin Kouba (JIRA)
Martin Kouba created CDI-629:
--------------------------------
Summary: Consider standardizing AnnotationInstaceProvider from DeltaSpike
Key: CDI-629
URL: https://issues.jboss.org/browse/CDI-629
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Martin Kouba
Fix For: 2.0 (discussion)
http://lists.jboss.org/pipermail/cdi-dev/2016-September/008829.html
Impl. notes:
* the type safety is not guaranteed in the current version of
{{AnnotationInstanceProvider}} (deltaspike)
* {{AnnotationInstanceProvider}} implements {{Serializable}} but a user is allowed to provide a map instance which is not serializable or contains values which are not serializable
* the provided map of values should be copied (it can be mutable)
* we should at least check the provided map of member values against the set of declared methods
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand closed CDI-628.
------------------------------------
Resolution: Rejected
> 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, 7 months
[JBoss JIRA] (CDI-628) Allow overriding of Scope at Injection Point
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-628?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-628:
------------------------------------------
-1 as well. It could looks like a nice feature but as others said it breaks CDI concept and will need to a nightmare. Using extensions or a producer to declare a new bean with a different scope from an existing dependent bean seems a better choice.
> 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, 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:
----------------------------------------
bq. Not legal and should not work.
Well CDI doesn't solve it so we have to provide a real life solution to solve your @PreDestroy issue in an extension but should be solve by this jira so let's skip this one since it was a pre-solution case ;)
bq. I don't think it's needed.
Agree before doesnt make sense but weird to not be symmetric there from a user perspective. I would at least enhance the After behavior
> 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-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:
-----------------------------------
Imo no concern as we just fix a regression introduced in the 1.2 wording. One could argue that this limitation is actually not valid for 1.2 anyway as we must not introduce such backward incompat changes in a follow up spec version.
> 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 Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-625?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-625:
----------------------------------
bq. BeforeShutdown extensions are often accessing app scoped beans...
Not legal and should not work.
bq. @AfterDestroyed for the consistency...
Yep, we could introduce {{@AfterDestroyed}} and deprecate {{@Destroyed}}. The event could be fired with both of these qualifiers - the old observers (with {{@Destroyed}}) should still work as they have a subset of the event qualifiers.
bq. and do the same for @Initialized
I don't think it's needed.
> 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:
----------------------------------------
You can always remove @PreDestroy in an extension and call it in Bean3 but was more thinking this way: since the user hits this issue the workaround is to not use @PreDestroy when it is an issue or order is important (which is not that common compared to @PreDestroy cases).
Right about BeforeShutdown, know early OWB versions needed to move it before the actual destruction in some cases (could check the details and current state if needed) cause BeforeShutdown extensions are often accessing app scoped beans which was not possible in the mentionned order, maybe no more an issue with this new @BeforeDestroyed.
About the semantic if we introduce @BeforeDestroyed we should likely introduce @AfterDestroyed for the consistency and do the same for @Initialized which would let us with two events doing the same in term or API (but easily collapsable in the implementation so no perf issue, just an API issue). Is that possible to deprecate not prefixed events? Or maybe @AfterXX should be a @Stereotype which would auto document the new API?
> 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:
----------------------------------
bq. ...it is always possible to use predestroy merging them in a bean...
Not really. If you have application scoped Bean1 and Bean2 you cannot simply create Bean3 and destoy them there... in other words, this "merging" is not always possible.
bq. is beforeshutdown defined in this shutdown lifecycle?
{{BeforeShutdown}} is a container lifecycle event and is fired after all contexts are destroyed.
> 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:
----------------------------------------
[~mkouba] being said today the behavior is uniform and the predestroy issue you describe actual it is always possible to use predestroy merging them in a bean (or more commonly having an orchestrator bean intended for the destruction)
is beforeshutdown defined in this shutdown lifecycle? if not shouldnt it be the solution? I know it has been prevented but supporting it in any bean would work I think
> 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] Yep, the CDI-provided literals are not used yet and I agree it's a backward compatibility risk. However, {{@PreDestroy}} CANNOT always replace this functionality - the ordering of destruction is not defined and so beans are not allowed to call other beans from within {{@PreDestroy}} callback (see also CDI-625).
[~struberg] [~emilyj] So I believe we should introduce a new event, for all built-in scopes. {{(a)PreDestroying(X.class)}} is imho confusing. Maybe something like {{(a)BeforeDestroyed(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