September 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-70) Clarify that if an extension provides an Annotated* then it is considered "metadata complete"

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-70?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-70: ------------------------- Fix Version/s: 1.1 (Proposed) (was: 1.1.EDR) Forum Reference: http://lists.jboss.org/pipermail/weld-dev/2010-January/002156.html (was: http://lists.jboss.org/pipermail/weld-dev/2010-January/002156.html) > Clarify that if an extension provides an Annotated* then it is considered "metadata complete" > --------------------------------------------------------------------------------------------- > > Key: CDI-70 > URL: https://issues.jboss.org/browse/CDI-70 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1 (Proposed) > > > I think the correct behavior is to ignore any members that are missing from the AnnotatedType. You should not be directly accessing the reflection API at all. If the parameters for a method or a constructor don't match the underlying class, it should be considered a definition error. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-178) Require container-provided InjectionTarget implementation to use getInjectionPoints()

by Jozef Hartinger (Created) (JIRA)

Require container-provided InjectionTarget implementation to use getInjectionPoints() ------------------------------------------------------------------------------------- Key: CDI-178 URL: https://issues.jboss.org/browse/CDI-178 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Affects Versions: 1.0 Reporter: Jozef Hartinger Priority: Minor Fix For: 1.1 (Proposed) A CDI extension should be able to turn a field of a into a CDI injection point as easily as by overriding the getInjectionPoints() method of the container-provided InjectionTarget implementation e.g.: {code} event.setInjectionTarget(decorate(event.getInjectionTarget())); ... protected <T> InjectionTarget<T> decorate(final InjectionTarget<T> delegate) { return new ForwardingInjectionTarget<T>() { @Override public Set<InjectionPoint> getInjectionPoints() { Set<InjectionPoint> injectionPoints = new HashSet<InjectionPoint>(); injectionPoints.addAll(super.getInjectionPoints()); injectionPoints.addAll(); // additional injection points return injectionPoints; } @Override protected InjectionTarget<T> delegate() { return delegate; } }; } {code} However, the spec does not require the container-provided InjectionTarget implementation to make use of the getInjectionPoint() method when creating a new instance. As a result, the approach above may or may not work. Therefore, it is currently necessary for a portable extension to also provide an implementation of at least the inject() method (for field injection points) and implement the injection itself. This is problematic in 1.0 of the spec since a portable does not necessarily have access to the BeanManager instance of the BDA where the injection target is deployed, thus different visibility rules apply. Clarify that the container-provided implementation of the Producer interface should use the result of the getInjectionPoints() method as a source of information about the injection points to inject. -- 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, 9 months

6
10
0 / 0

[JBoss JIRA] (CDI-250) The usage of name and EL name is very inconsistent in the spec

by Pete Muir (JIRA)

Pete Muir created CDI-250: ----------------------------- Summary: The usage of name and EL name is very inconsistent in the spec Key: CDI-250 URL: https://issues.jboss.org/browse/CDI-250 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.1.EDR1 Reporter: Pete Muir Fix For: 1.1 (Proposed) The spec jumps around between Bean name, Bean EL name and name. I would propose we just call it the "bean name". -- 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, 9 months

1
5
0 / 0

[JBoss JIRA] Created: (CDI-124) Clarify how the ObserverMethod interface should be used

by Jozef Hartinger (JIRA)

Clarify how the ObserverMethod interface should be used ------------------------------------------------------- Key: CDI-124 URL: https://issues.jboss.org/browse/CDI-124 Project: CDI Specification Issues Issue Type: Clarification Components: Events Affects Versions: 1.0 Reporter: Jozef Hartinger Fix For: TBD The CDI specification (10.5) says: "For a custom implementation of the ObserverMethod interface defined in Section 11.1.3, "The ObserverMethod interface", the container must call getReception() and getTransactionPhase() to determine if the observer method is a conditional or transactional observer method, and notify() to invoke the method." However, calling ObserverMethod.getReception() is useless. An ObserverMethod implementation can be registered by an portable extension via the AfterBeanDiscovery event. The observer method may or may not be hosted by a CDI bean: a) A portable extension adds a different way of declaring an observer method on a CDI bean (e.g. using a different annotation like @Listens, or allowing a different method signature) b) A portable extension allows CDI observer methods to be registered on non-CDI beans (e.g. on a Spring Bean) In both cases, the container is not able find out if an instance of the hosting component has been created already - it does not know the hosting bean in (a) and it obviously does not know anything about the Spring bean (b). Therefore, if the observer method is conditional (ObserverMethod.getReception() returns IF_EXISTS), the container cannot decide whether it should invoke the observer method since it has no way of finding out whether the underlying instance exists or not. As a result, the container has to invoke ObserverMethod.notify() anyway. That's why I consider ObserverMethod.getReception() useless. To fix the problem, I think that the responsibility of deciding whether to invoke a conditional observer method should be shifted from container to the ObserverMethod implementation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

2
4
0 / 0

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

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-15?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger commented on CDI-15: ------------------------------------ Also, the spec currently contradicts itself when it says: {quote} A qualifier type is a Java annotation defined as @Target(\{METHOD, FIELD, PARAMETER, TYPE\}) and @Retention(RUNTIME). {quote} and then uses {code:JAVA} @Qualifier @Target(PARAMETER) @Retention(RUNTIME) public @interface Role { String value(); } {code} in 10.2.2 of CDI 1.0 > 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, 9 months

1
0
0 / 0

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

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-15?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger commented on CDI-15: ------------------------------------ Also, there may be cases where restricting a custom qualifier more than the spec requires @Target({METHOD, FIELD, PARAMETER, TYPE}) would be handy (e.g. FIELD and PARAMETER only for a qualifier marking special bean which can be injected but no other equally qualified bean can be produced). > 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, 9 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: TBD) > 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, 9 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 (Proposed) (was: 1.1.PRD) > 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 (Proposed) > > > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-77) Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-77?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-77: ------------------------- Fix Version/s: 1.1 (Proposed) (was: 1.1.PRD) > Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans > ---------------------------------------------------------------------------------------------------- > > Key: CDI-77 > URL: https://issues.jboss.org/browse/CDI-77 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1 (Proposed) > > > for example > class Foo { > @Inject Bar bar; > } > class bar { > @Inject Foo foo; > } -- 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, 9 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 (Proposed) (was: 1.1.PRD) > 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 (Proposed) > > > 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, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2012