October 2016 - cdi-dev - Jboss List Archives

[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/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)

7 years, 7 months

1
0
0 / 0

[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: 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)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-270) Allow @WithAnnotations to be applied to other events

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-270?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-270: ------------------------------------- Fix Version/s: 2.1 (Discussion) (was: 2.0 (discussion)) > Allow @WithAnnotations to be applied to other events > ---------------------------------------------------- > > Key: CDI-270 > URL: https://issues.jboss.org/browse/CDI-270 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Labels: with-annotations > Fix For: 2.1 (Discussion) > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[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 > ------------------------------------------------------------------------------------------------------------------------------------------- > > 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)

7 years, 7 months

1
0
0 / 0

[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 > ------------------------------------------------------------------------------------------------------------------------------------------- > > 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)

7 years, 7 months

1
0
0 / 0

[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 > 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)

7 years, 7 months

1
0
0 / 0

[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 > 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)

7 years, 7 months

1
0
0 / 0

[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 > 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)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-362) No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-362: ------------------------------------- Fix Version/s: TBD (was: 2.0 (discussion)) > No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting > --------------------------------------------------------------------------------------------- > > Key: CDI-362 > URL: https://issues.jboss.org/browse/CDI-362 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Pete Muir > Priority: Minor > Fix For: TBD > > > E.g. > // allowed by EJB > // disallowed by CDI > @Stateful @RequestScoped > public class MyBean { > final void m() { }; > } > public class Other { > @EJB MyBean field; // PASS > @Inject MyBean field; // FAIL - unproxyable > } -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-362) No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-362?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-362: ------------------------------------- Priority: Minor (was: Major) > No-interface view EJB proxying rules are less strict than CDI, leading to odd error reporting > --------------------------------------------------------------------------------------------- > > Key: CDI-362 > URL: https://issues.jboss.org/browse/CDI-362 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Pete Muir > Priority: Minor > Fix For: TBD > > > E.g. > // allowed by EJB > // disallowed by CDI > @Stateful @RequestScoped > public class MyBean { > final void m() { }; > } > public class Other { > @EJB MyBean field; // PASS > @Inject MyBean field; // FAIL - unproxyable > } -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2016