May 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Updated: (CDI-78) Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-78: ------------------------- Proposed fix https://github.com/jboss/cdi/pull/21 > Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator > ------------------------------------------------------------------------------------------------------------------------ > > Key: CDI-78 > URL: https://issues.jboss.org/browse/CDI-78 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1 (Proposed) > > > The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

Review of proposed fix for CDI-78

by Pete Muir

Hi Please review the proposed fix for https://issues.jboss.org/browse/CDI-78 Thanks!

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-78) Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-78: ------------------------- Assignee: Pete Muir > Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator > ------------------------------------------------------------------------------------------------------------------------ > > Key: CDI-78 > URL: https://issues.jboss.org/browse/CDI-78 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1 (Proposed) > > > The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-2) Interceptor bindings defined at method level should override those at the class level

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-2?page=com.atlassian.jira.plugin.syst... ] Pete Muir commented on CDI-2: ----------------------------- I'm not sure why we are defining what a non-binding property must do given we declare that it is not actually relevant to this. Otherwise I like it and look forward to seeing it written up :-) > Interceptor bindings defined at method level should override those at the class level > ------------------------------------------------------------------------------------- > > Key: CDI-2 > URL: https://issues.jboss.org/browse/CDI-2 > Project: CDI Specification Issues > Issue Type: Bug > Components: Interceptors > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Marius Bogoevici > Fix For: 1.1 (Proposed) > > > Gavin said: > "We certainly *intended* for method-level interceptor bindings to override bindings declared at the class level, but whether we actually wrote that down is another story. It certainly doesn't look like that behavior is properly defined in the latest version of the spec." > In section 9.5.2 of the spec: > If the set of interceptor bindings of a bean or interceptor, including bindings inherited from stereotypes and other interceptor bindings, has two instances of a certain interceptor binding type and the instances have different values of some annotation member, the container automatically detects the problem and treats it as a definition error. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] Issue Comment Edited: (CDI-28) Abstract methods on decorators

by Marius Bogoevici (JIRA)

[ https://issues.jboss.org/browse/CDI-28?page=com.atlassian.jira.plugin.sys... ] Marius Bogoevici edited comment on CDI-28 at 5/23/11 1:51 PM: -------------------------------------------------------------- George, Service Handlers is a different story (with the potential of being complementary if you will). Here we just leave decorator implementors to forgo stuff like {code} void decoratedMethod() { return delegate.decoratedMethod(); } {code} and leave decoratedMethod() unimplemented instead. was (Author: marius.bogoevici): George, Service Handlers is a different story (with the potential of being complementary if you will). Here we just leave decorator implementors to forgo stuff like void decoratedMethod() { return delegate.decoratedMethod(); } and leave decoratedMethod() unimplemented instead. > Abstract methods on decorators > ------------------------------ > > Key: CDI-28 > URL: https://issues.jboss.org/browse/CDI-28 > Project: CDI Specification Issues > Issue Type: Bug > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Marius Bogoevici > Fix For: 1.1 (Proposed) > > > If a method is abstract: > * if it is a method of a decorated type, it has a generated implementation that calls the delegate > * otherwise, definition error -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-28) Abstract methods on decorators

by Marius Bogoevici (JIRA)

[ https://issues.jboss.org/browse/CDI-28?page=com.atlassian.jira.plugin.sys... ] Marius Bogoevici commented on CDI-28: ------------------------------------- George, Service Handlers is a different story (with the potential of being complementary if you will). Here we just leave decorator implementors to forgo stuff like void decoratedMethod() { return delegate.decoratedMethod(); } and leave decoratedMethod() unimplemented instead. > Abstract methods on decorators > ------------------------------ > > Key: CDI-28 > URL: https://issues.jboss.org/browse/CDI-28 > Project: CDI Specification Issues > Issue Type: Bug > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Marius Bogoevici > Fix For: 1.1 (Proposed) > > > If a method is abstract: > * if it is a method of a decorated type, it has a generated implementation that calls the delegate > * otherwise, definition error -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] Issue Comment Edited: (CDI-2) Interceptor bindings defined at method level should override those at the class level

by Marius Bogoevici (JIRA)

[ https://issues.jboss.org/browse/CDI-2?page=com.atlassian.jira.plugin.syst... ] Marius Bogoevici edited comment on CDI-2 at 5/23/11 1:43 PM: ------------------------------------------------------------- Here is my suggestion on solving this: 1) Interceptors: If an interceptor *inherits* multiple binding instances from its stereotypes, bindings, parent class - they must either have the same values (including nonbinding values) or the interceptor must disambiguate by defining its own interceptor binding instance. This is consistent with the behaviour of scopes - the goal is to be able to answer the question "What are the bindings of interceptor X and their properties" in an unambiguous fashion a) this is backwards compatible in the sense that it will not cause CDI 1.0 applications to fail and it will allow a more lenient mechanism for 1.1. b) nonbinding properties must be identical, even if they do not play a role in interceptor resolution, since they may be used for other purposes 2) Beans must observe the same rule as described by point 1 for class-level bindings. 3) Obviously, even if the inherited set at point 1 and 2 wasn't ambiguous, the presence at the class level will override the binding for the class and its descendands 4) Beans may define bindings at method level which override bindings at class level, were they inherited or explicitely defined. was (Author: marius.bogoevici): Here is my suggestion on solving this: 1) Interceptors: If an interceptor *inherits* multiple binding instances from its stereotypes, bindings, parent class - they must either have the same values (including nonbinding values) or the interceptor must disambiguate by defining its own interceptor binding instance. This is consistent with the behaviour of scopes - the goal is to be able to answer the question "What are the bindings of interceptor X and their properties" in an unambiguous fashion a) this is backwards compatible in the sense that it will not cause CDI 1.0 applications to fail and it will allow a more lenient mechanism for 1.1. b) nonbinding properties must be identical, even if they do not play a role in interceptor resolution, since they may be used for other purposes 2) Beans must observe the same rule as described by point 1 for class-level bindings. 3) Obviously, even if the inherited set at point 1 and 2 wasn't ambiguous, the presence at the class level will override the binding for the class and its descendands 4) Beans may define bindings at method level which override bindings at class level, inherited or explicitely defined. > Interceptor bindings defined at method level should override those at the class level > ------------------------------------------------------------------------------------- > > Key: CDI-2 > URL: https://issues.jboss.org/browse/CDI-2 > Project: CDI Specification Issues > Issue Type: Bug > Components: Interceptors > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Marius Bogoevici > Fix For: 1.1 (Proposed) > > > Gavin said: > "We certainly *intended* for method-level interceptor bindings to override bindings declared at the class level, but whether we actually wrote that down is another story. It certainly doesn't look like that behavior is properly defined in the latest version of the spec." > In section 9.5.2 of the spec: > If the set of interceptor bindings of a bean or interceptor, including bindings inherited from stereotypes and other interceptor bindings, has two instances of a certain interceptor binding type and the instances have different values of some annotation member, the container automatically detects the problem and treats it as a definition error. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] Issue Comment Edited: (CDI-2) Interceptor bindings defined at method level should override those at the class level

by Marius Bogoevici (JIRA)

[ https://issues.jboss.org/browse/CDI-2?page=com.atlassian.jira.plugin.syst... ] Marius Bogoevici edited comment on CDI-2 at 5/23/11 1:42 PM: ------------------------------------------------------------- Here is my suggestion on solving this: 1) Interceptors: If an interceptor *inherits* multiple binding instances from its stereotypes, bindings, parent class - they must either have the same values (including nonbinding values) or the interceptor must disambiguate by defining its own interceptor binding instance. This is consistent with the behaviour of scopes - the goal is to be able to answer the question "What are the bindings of interceptor X and their properties" in an unambiguous fashion a) this is backwards compatible in the sense that it will not cause CDI 1.0 applications to fail and it will allow a more lenient mechanism for 1.1. b) nonbinding properties must be identical, even if they do not play a role in interceptor resolution, since they may be used for other purposes 2) Beans must observe the same rule as described by point 1 for class-level bindings. 3) Obviously, even if the inherited set at point 1 and 2 wasn't ambiguous, the presence at the class level will override the binding for the class and its descendands 4) Beans may define bindings at method level which override bindings at class level, inherited or explicitely defined. was (Author: marius.bogoevici): Here is my suggestion on solving this: 1) Interceptors: If an interceptor *inherits* multiple binding instances from its stereotypes, bindings, parent class - they must either have the same values (including nonbinding values) or the interceptor must disambiguate by defining its own interceptor binding instance. This is consistent with the behaviour of scopes - the goal is to be able to answer the question "What are the bindings of interceptor X and their properties" in an unambiguous fashion a) this is backwards compatible in the sense that it will not cause CDI 1.0 applications to fail and it will allow a more lenient mechanism for 1.1. b) nonbinding properties must be identical, even if they do not play a role in interceptor resolution, since they may be used for other purposes 2) For beans, we may observe the same rule as described by point 1, at both class level. 3) Obviously, even if the inherited set at point 1 and 2 wasn't ambiguous, the presence at the class level will override the binding for the class and its descendands 4) Beans may define bindings at method level which override bindings at class level, inherited or explicitely defined. > Interceptor bindings defined at method level should override those at the class level > ------------------------------------------------------------------------------------- > > Key: CDI-2 > URL: https://issues.jboss.org/browse/CDI-2 > Project: CDI Specification Issues > Issue Type: Bug > Components: Interceptors > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Marius Bogoevici > Fix For: 1.1 (Proposed) > > > Gavin said: > "We certainly *intended* for method-level interceptor bindings to override bindings declared at the class level, but whether we actually wrote that down is another story. It certainly doesn't look like that behavior is properly defined in the latest version of the spec." > In section 9.5.2 of the spec: > If the set of interceptor bindings of a bean or interceptor, including bindings inherited from stereotypes and other interceptor bindings, has two instances of a certain interceptor binding type and the instances have different values of some annotation member, the container automatically detects the problem and treats it as a definition error. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-2) Interceptor bindings defined at method level should override those at the class level

by Marius Bogoevici (JIRA)

[ https://issues.jboss.org/browse/CDI-2?page=com.atlassian.jira.plugin.syst... ] Marius Bogoevici commented on CDI-2: ------------------------------------ Here is my suggestion on solving this: 1) Interceptors: If an interceptor *inherits* multiple binding instances from its stereotypes, bindings, parent class - they must either have the same values (including nonbinding values) or the interceptor must disambiguate by defining its own interceptor binding instance. This is consistent with the behaviour of scopes - the goal is to be able to answer the question "What are the bindings of interceptor X and their properties" in an unambiguous fashion a) this is backwards compatible in the sense that it will not cause CDI 1.0 applications to fail and it will allow a more lenient mechanism for 1.1. b) nonbinding properties must be identical, even if they do not play a role in interceptor resolution, since they may be used for other purposes 2) For beans, we may observe the same rule as described by point 1, at both class level. 3) Obviously, even if the inherited set at point 1 and 2 wasn't ambiguous, the presence at the class level will override the binding for the class and its descendands 4) Beans may define bindings at method level which override bindings at class level, inherited or explicitely defined. > Interceptor bindings defined at method level should override those at the class level > ------------------------------------------------------------------------------------- > > Key: CDI-2 > URL: https://issues.jboss.org/browse/CDI-2 > Project: CDI Specification Issues > Issue Type: Bug > Components: Interceptors > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Marius Bogoevici > Fix For: 1.1 (Proposed) > > > Gavin said: > "We certainly *intended* for method-level interceptor bindings to override bindings declared at the class level, but whether we actually wrote that down is another story. It certainly doesn't look like that behavior is properly defined in the latest version of the spec." > In section 9.5.2 of the spec: > If the set of interceptor bindings of a bean or interceptor, including bindings inherited from stereotypes and other interceptor bindings, has two instances of a certain interceptor binding type and the instances have different values of some annotation member, the container automatically detects the problem and treats it as a definition error. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (CDI-52) Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-52?page=com.atlassian.jira.plugin.sys... ] Pete Muir closed CDI-52. ------------------------ Assignee: Pete Muir Fix Version/s: 1.1 (Confirmed) (was: 1.1 (Proposed)) Resolution: Done > Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-52 > URL: https://issues.jboss.org/browse/CDI-52 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1 (Confirmed) > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev May 2011