[JBoss JIRA] (CDI-248) Provide means to observe a group of qualified events ("Qualifier Inheritance"?)
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-248?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-248:
-------------------------------------
Fix Version/s: TBD
(was: 2.0 (discussion))
> Provide means to observe a group of qualified events ("Qualifier Inheritance"?)
> --------------------------------------------------------------------------------
>
> Key: CDI-248
> URL: https://issues.jboss.org/browse/…
[View More]CDI-248
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Concepts, Events
> Reporter: Jens Schumann
> Fix For: TBD
>
>
> We have been using CDI events for application development quite extensively. For instance we use events to propagate entity lifecycle events (@Created/@Updated/@Deleted Customer customer) or GUI selections (@Selected/@Deselected Customer customer) and implement related business logic in event observers. (e.g. send email for newly created customers, clear cached values on select/deselect/create/update/delete ...).
> This works quite well, however we have noticed that especially our JSF Presentation Tier contains lots of observer methods implementing the same behavior for a group of related CDI events.
> Example:
> {code}
> public class XyzBean {
> public void onCustomerCreate(@Observes @Created Customer customer) { reset();}
> public void onCustomerUpdate(@Observes @Updated Customer customer) { reset();}
> public void onCustomerDelete(@Observes @Deleted Customer customer) { reset();}
>
> }
> {code}
> Looks ugly, doesn't it?
> The above example could be improved if CDI would be able to observe a group of qualified events, e.g. public void onCustomerLifeCycleEvent(@Observes @LifeCycleChange Customer customer) { reset(); } - ignore method and qualifier names for now.
> Since Java does not support annotation inheritance grouping could be achieved using "qualified qualifier annotations":
> {code}
> @Qualifier
> public @interface LifeCycleChange
> @Qualifier
> @LifeCycleChange
> public @interface Created
> @Qualifier
> @LifeCycleChange
> public @interface Updated
> @Qualifier
> @LifeCycleChange
> public @interface Deleted
> @Qualifier
> public @interface SelectionChange
> @Qualifier
> @SelectionChange
> public @interface Selected
> @Qualifier
> @SelectionChange
> public @interface Deselected
> {code}
> WDYT? Side effects? Problems?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 6 months
[JBoss JIRA] (CDI-248) Provide means to observe a group of qualified events ("Qualifier Inheritance"?)
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-248?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-248:
-------------------------------------
Priority: Minor (was: Major)
> Provide means to observe a group of qualified events ("Qualifier Inheritance"?)
> --------------------------------------------------------------------------------
>
> Key: CDI-248
> URL: https://issues.jboss.org/browse/CDI-248
> Project: …
[View More]CDI Specification Issues
> Issue Type: Feature Request
> Components: Concepts, Events
> Reporter: Jens Schumann
> Priority: Minor
> Fix For: TBD
>
>
> We have been using CDI events for application development quite extensively. For instance we use events to propagate entity lifecycle events (@Created/@Updated/@Deleted Customer customer) or GUI selections (@Selected/@Deselected Customer customer) and implement related business logic in event observers. (e.g. send email for newly created customers, clear cached values on select/deselect/create/update/delete ...).
> This works quite well, however we have noticed that especially our JSF Presentation Tier contains lots of observer methods implementing the same behavior for a group of related CDI events.
> Example:
> {code}
> public class XyzBean {
> public void onCustomerCreate(@Observes @Created Customer customer) { reset();}
> public void onCustomerUpdate(@Observes @Updated Customer customer) { reset();}
> public void onCustomerDelete(@Observes @Deleted Customer customer) { reset();}
>
> }
> {code}
> Looks ugly, doesn't it?
> The above example could be improved if CDI would be able to observe a group of qualified events, e.g. public void onCustomerLifeCycleEvent(@Observes @LifeCycleChange Customer customer) { reset(); } - ignore method and qualifier names for now.
> Since Java does not support annotation inheritance grouping could be achieved using "qualified qualifier annotations":
> {code}
> @Qualifier
> public @interface LifeCycleChange
> @Qualifier
> @LifeCycleChange
> public @interface Created
> @Qualifier
> @LifeCycleChange
> public @interface Updated
> @Qualifier
> @LifeCycleChange
> public @interface Deleted
> @Qualifier
> public @interface SelectionChange
> @Qualifier
> @SelectionChange
> public @interface Selected
> @Qualifier
> @SelectionChange
> public @interface Deselected
> {code}
> WDYT? Side effects? Problems?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 6 months
[JBoss JIRA] (CDI-279) Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-279?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-279:
-------------------------------------
Priority: Minor (was: Major)
> Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> …
[View More] Key: CDI-279
> URL: https://issues.jboss.org/browse/CDI-279
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Hong Zhang
> Assignee: Pete Muir
> Priority: Minor
> Fix For: TBD
>
>
> Please provide CDI SPI that could be used to directly replace the java.lang.reflect methods when expanding the use of @Stereotype to Java EE 7 platform.
> Also attaching the relevant sections from Bill's @Stereotype proposal below:
> ================================================
> Stereotypes are implemented by CDI, but (typically) the Java EE deployment processing has no knowledge of CDI when it's looking for Java EE annotations. Integrating with CDI so that stereotypes could be considered during this deployment-time annotation processing would require a new CDI SPI.
> Many existing implementations would need to be changed to understand
> how to expand stereotypes. Requiring every technology to do this
> itself will almost certainly lead to inconsistencies. Since stereotypes
> are a CDI feature, CDI will provide a simple replacement for the
> java.lang.reflect methods such as getAnnotations that takes into
> account stereotypes.
> Some technologies will not want to have a hard dependency on CDI so
> we'll need to provide a simple way for them to conditionally invoke
> these new methods only if CDI is present, falling back to java.lang.reflect
> if not. This seems straightforward. In this case, the functionality of
> @Stereotype would not be available to applications that chose to run
> without CDI.
> ===============================
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 6 months
[JBoss JIRA] (CDI-279) Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-279?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-279:
-------------------------------------
Fix Version/s: TBD
(was: 2.0 (discussion))
> Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform
> ------------------------------------------------------------------------------------------------------------------------…
[View More]-------------------
>
> Key: CDI-279
> URL: https://issues.jboss.org/browse/CDI-279
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Hong Zhang
> Assignee: Pete Muir
> Fix For: TBD
>
>
> Please provide CDI SPI that could be used to directly replace the java.lang.reflect methods when expanding the use of @Stereotype to Java EE 7 platform.
> Also attaching the relevant sections from Bill's @Stereotype proposal below:
> ================================================
> Stereotypes are implemented by CDI, but (typically) the Java EE deployment processing has no knowledge of CDI when it's looking for Java EE annotations. Integrating with CDI so that stereotypes could be considered during this deployment-time annotation processing would require a new CDI SPI.
> Many existing implementations would need to be changed to understand
> how to expand stereotypes. Requiring every technology to do this
> itself will almost certainly lead to inconsistencies. Since stereotypes
> are a CDI feature, CDI will provide a simple replacement for the
> java.lang.reflect methods such as getAnnotations that takes into
> account stereotypes.
> Some technologies will not want to have a hard dependency on CDI so
> we'll need to provide a simple way for them to conditionally invoke
> these new methods only if CDI is present, falling back to java.lang.reflect
> if not. This seems straightforward. In this case, the functionality of
> @Stereotype would not be available to applications that chose to run
> without CDI.
> ===============================
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 6 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-280:
-------------------------------------
Priority: Minor (was: Major)
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
> Key: CDI-280
> URL: https://issues.jboss.org/browse/CDI-280
> Project: CDI Specification Issues
> Issue Type: Clarification
> …
[View More] Reporter: Mark Struberg
> Assignee: Antoine Sabot-Durand
> Priority: Minor
> Labels: CDI_api_chge, CDI_spec_chge
> Fix For: TBD
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 6 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-280:
-------------------------------------
Fix Version/s: TBD
(was: 2.0 (discussion))
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
> Key: CDI-280
> URL: https://issues.jboss.org/browse/CDI-280
> Project: CDI Specification Issues
> …
[View More] Issue Type: Clarification
> Reporter: Mark Struberg
> Assignee: Antoine Sabot-Durand
> Labels: CDI_api_chge, CDI_spec_chge
> Fix For: TBD
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 6 months
[JBoss JIRA] (CDI-291) Clarify interceptor/decorator resolution rules
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-291?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-291:
-------------------------------------
Fix Version/s: TBD
(was: 2.0 (discussion))
> Clarify interceptor/decorator resolution rules
> ----------------------------------------------
>
> Key: CDI-291
> URL: https://issues.jboss.org/browse/CDI-291
> Project: CDI Specification Issues
> …
[View More] Issue Type: Clarification
> Components: Decorators, Interceptors
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Fix For: TBD
>
>
> Currently the spec only says:
> {quote}
> A decorator is bound to a bean if:
> * The bean is assignable to the delegate injection point according to the rules defined in Section 5.2, "Typesafe resolu-
> tion" (using Section 8.3.1, "Assignability of raw and parameterized types for delegate injection points").
> * The decorator is enabled in the bean archive containing the bean.
> {quote}
> AND
> {quote}
> An interceptor is bound to a method if:
> * The method has all the interceptor bindings of the interceptor. A method has an interceptor binding of an interceptor if
> it has an interceptor binding with (a) the same type and (b) the same annotation member value for each member which
> is not annotated @javax.enterprise.util.Nonbinding.
> * The interceptor intercepts the given kind of lifecycle callback or business method.
> * The interceptor is enabled in the bean archive containing the bean.
> {quote}
> What remains unspecified is:
> * In a scenario where a module A enables interceptor X in its beans.xml, does X have to be accessible from A. That effectively means that an EJB jar could (or could not) legally use an interceptor/decorator packaged in a web application.
> * Even if X is accessible, does it have to be packaged in a bean archive or is it enough for it to be packaged in a library that does not contain beans.xml but is accessible from A? This means that a CDI implementation would need to additionally scan those classes as they would not be scanned by normal bean archive discovery.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 6 months