September 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-227) API is underspecified for corner cases

by Guy Veraghtert (JIRA)

Guy Veraghtert created CDI-227: ---------------------------------- Summary: API is underspecified for corner cases Key: CDI-227 URL: https://issues.jboss.org/browse/CDI-227 Project: CDI Specification Issues Issue Type: Bug Components: Java SE Integration, Packaging and Deployment Affects Versions: 1.1.EDR1, 1.0 Reporter: Guy Veraghtert The CDI api's are mainly used to develop (portable) extensions. In practice, we see that those so called _portable_ extensions are not portable at all due to underspecified api's. For example BeanManager.resolve(set) doesn't specify how to deal with an empty set or null. This leads to incompatible implementations and unportable extensions. See for example https://issues.apache.org/jira/browse/OWB-625 (Unfortunately Websphere 8 includes openwebbeans < 1.1.3, making Seam3 not out-of-the-box usable). Currently most implementations (weld, owb and candi) return null for an empty set. OWB returns null when null is passed, others will throw an exception. To create extensions that are truly portable, we should specify all corner cases (what about BeanManager.getBean((String)null)?). In theory developers should not depend on undefined behavior, but in practice we all do (Seam3 is full of examples). Ideally, we should go over the complete public API and specify what should happen with these corner cases: null-values, empty collections, ... Just adding that an IllegalArgumentException should be thrown in case of null for example would suffice. These things are very easy to incorporate in the TCK and would contribute a lot to the success of portable extensions -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

5
20
0 / 0

[JBoss JIRA] (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 commented on CDI-52: ------------------------------ I'm going to back out these changes. Jozef also notes we need to disallow injection of Bean into a disposer method > 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 > Priority: Critical > Fix For: 1.1 (Proposed) > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-44?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-44: ------------------------- Fix Version/s: 1.1.PRD (was: 1.1 (Proposed)) > Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation > ------------------------------------------------------------------------------------------------------------- > > Key: CDI-44 > URL: https://issues.jboss.org/browse/CDI-44 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: 1.1.PRD > > > When implementing interception using proxying the behaour of self invocation is quite well defined, if a method is invoked on the proxy it is intercepted, if it is invoked on the actual bean (usually through self-invocation) it is not. > When implementing interception though sub classing this is much less well definied, and the only way to track if an invocation is intercepted or not is through a thread local flag. At the moment in weld this is reset when a call is made on a client proxy, so if we have an intercepted bean A and a SessionScoped bean B and A invokes B when invokes A the second call to A is intercepted. If however B is pseudo scoped, then the second invocation is not intercepted. The correct behaviour here should be specified by the specification. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-74) State explicitely that Decorators must be implemented using subclassing

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-74?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-74: ------------------------- Fix Version/s: 1.1.PRD (was: 1.1 (Proposed)) Forum Reference: http://lists.jboss.org/pipermail/weld-dev/2010-May/002506.html (was: http://lists.jboss.org/pipermail/weld-dev/2010-May/002506.html) New pull request at https://github.com/jboss/cdi/pull/126 to review. > State explicitely that Decorators must be implemented using subclassing > ----------------------------------------------------------------------- > > Key: CDI-74 > URL: https://issues.jboss.org/browse/CDI-74 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators > Affects Versions: 1.0 > Reporter: Marius Bogoevici > Assignee: Pete Muir > Fix For: 1.1.PRD > > > Subclassing should be mandatory for Decorators of managed beans which are not session beans (no restrictions in the case of the latter). > This ensures that: > (1) fields on pseudo scoped managed beans are accessible > (2) there's no restriction on what kinds of constructors may a managed bean have > (3) no extra bean instances are created when a managed bean is created -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-6) Clarify InjectionTarget method parameters

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-6?page=com.atlassian.jira.plugin.syst... ] Pete Muir updated CDI-6: ------------------------ Fix Version/s: 1.1.PRD (was: 1.1 (Proposed)) > Clarify InjectionTarget method parameters > ----------------------------------------- > > Key: CDI-6 > URL: https://issues.jboss.org/browse/CDI-6 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Jozef Hartinger > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.PRD > > > For the inject() method, the spec says: "inject() performs dependency injection upon the given object". It is not clear to me what does the "given object" refer two. if the CDI implementation uses proxies to implement interceptors and decorators, I can see two candidates for "the given object": > - the product of the produce() method including interceptors and decorators -> a proxy > - the target instance -> the object created by calling a constructor (no interception/decoration) > Arguments for the first option > - Let's have and extension that adds additional dependency injection capabilities by providing a custom InjectionTarget implementation and wrapping default InjectionTarget instances with custom ones. The custom InjectionTarget implementation does the additional DI in the inject() method and delegates to the default InjectionTarget instance to finish the injection. This implementation needs a direct access to the target instance (it cannot access field values through a proxy) > - Interceptor-like behavior - similarity to interceptors, where the InvocationContext.getTarget() returns the (non-intercepted) target instance > Arguments for the second option > - the contract of the produce() method says: "produce() calls the constructor annotated @Inject if it exists, or the constructor with no parameters otherwise, as defined in Section 5.5.1, "Injection using the bean constructor", and returns the resulting instance. If the class has inter- ceptors, produce() is responsible for building the interceptors and decorators of the instance." which means it returns an intercepted/decorated instance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-44?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-44: ------------------------------ New pull request at https://github.com/jboss/cdi/pull/126 to review > Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation > ------------------------------------------------------------------------------------------------------------- > > Key: CDI-44 > URL: https://issues.jboss.org/browse/CDI-44 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: 1.1.PRD > > > When implementing interception using proxying the behaour of self invocation is quite well defined, if a method is invoked on the proxy it is intercepted, if it is invoked on the actual bean (usually through self-invocation) it is not. > When implementing interception though sub classing this is much less well definied, and the only way to track if an invocation is intercepted or not is through a thread local flag. At the moment in weld this is reset when a call is made on a client proxy, so if we have an intercepted bean A and a SessionScoped bean B and A invokes B when invokes A the second call to A is intercepted. If however B is pseudo scoped, then the second invocation is not intercepted. The correct behaviour here should be specified by the specification. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-6) Clarify InjectionTarget method parameters

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-6?page=com.atlassian.jira.plugin.syst... ] Pete Muir commented on CDI-6: ----------------------------- New pull request at https://github.com/jboss/cdi/pull/126 to review. > Clarify InjectionTarget method parameters > ----------------------------------------- > > Key: CDI-6 > URL: https://issues.jboss.org/browse/CDI-6 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Jozef Hartinger > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1 (Proposed) > > > For the inject() method, the spec says: "inject() performs dependency injection upon the given object". It is not clear to me what does the "given object" refer two. if the CDI implementation uses proxies to implement interceptors and decorators, I can see two candidates for "the given object": > - the product of the produce() method including interceptors and decorators -> a proxy > - the target instance -> the object created by calling a constructor (no interception/decoration) > Arguments for the first option > - Let's have and extension that adds additional dependency injection capabilities by providing a custom InjectionTarget implementation and wrapping default InjectionTarget instances with custom ones. The custom InjectionTarget implementation does the additional DI in the inject() method and delegates to the default InjectionTarget instance to finish the injection. This implementation needs a direct access to the target instance (it cannot access field values through a proxy) > - Interceptor-like behavior - similarity to interceptors, where the InvocationContext.getTarget() returns the (non-intercepted) target instance > Arguments for the second option > - the contract of the produce() method says: "produce() calls the constructor annotated @Inject if it exists, or the constructor with no parameters otherwise, as defined in Section 5.5.1, "Injection using the bean constructor", and returns the resulting instance. If the class has inter- ceptors, produce() is responsible for building the interceptors and decorators of the instance." which means it returns an intercepted/decorated instance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-15) Relax @Target annotation for CDI Scopes and Qualifiers

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-15?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-15: ------------------------------ Please review https://github.com/jboss/cdi/pull/125 > Relax @Target annotation for CDI Scopes and Qualifiers > ------------------------------------------------------ > > Key: CDI-15 > URL: https://issues.jboss.org/browse/CDI-15 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 1.1.PRD > > > In some cases it may make sense to apply a scope or qualifier in a place that was not envisaged by the spec but that would be useful for a portable extension. > For example, the @Constructs extension described at > http://www.seamframework.org/Weld/PortableExtensionsPackage#H-BeanDeclara... > is not possible because scopes and qualifiers can not be placed on constructors -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-15) Relax @Target annotation for CDI Scopes and Qualifiers

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-15?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-15: ------------------------- Assignee: Pete Muir > Relax @Target annotation for CDI Scopes and Qualifiers > ------------------------------------------------------ > > Key: CDI-15 > URL: https://issues.jboss.org/browse/CDI-15 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: 1.1.PRD > > > In some cases it may make sense to apply a scope or qualifier in a place that was not envisaged by the spec but that would be useful for a portable extension. > For example, the @Constructs extension described at > http://www.seamframework.org/Weld/PortableExtensionsPackage#H-BeanDeclara... > is not possible because scopes and qualifiers can not be placed on constructors -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-15) Relax @Target annotation for CDI Scopes and Qualifiers

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-15?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-15: ------------------------- Fix Version/s: 1.1.PRD (was: 1.1 (Proposed)) > Relax @Target annotation for CDI Scopes and Qualifiers > ------------------------------------------------------ > > Key: CDI-15 > URL: https://issues.jboss.org/browse/CDI-15 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: 1.1.PRD > > > In some cases it may make sense to apply a scope or qualifier in a place that was not envisaged by the spec but that would be useful for a portable extension. > For example, the @Constructs extension described at > http://www.seamframework.org/Weld/PortableExtensionsPackage#H-BeanDeclara... > is not possible because scopes and qualifiers can not be placed on constructors -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2012