August 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-243) Consider built-in InjectionPoint not available for stateless session beans

by Martin Kouba (JIRA)

Martin Kouba created CDI-243: -------------------------------- Summary: Consider built-in InjectionPoint not available for stateless session beans Key: CDI-243 URL: https://issues.jboss.org/browse/CDI-243 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba Right now it should be possible to inject InjectionPoint metadata to dependent SLSB (see 5.5.7. Injection point metadata). I think it may lead to inconsistencies - SLSB should not have any state as it is usually pooled and reused for every invocation. -- 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

3
9
0 / 0

[JBoss JIRA] (CDI-173) Improve javadoc for event-firing methods

by Jozef Hartinger (Created) (JIRA)

Improve javadoc for event-firing methods ---------------------------------------- Key: CDI-173 URL: https://issues.jboss.org/browse/CDI-173 Project: CDI Specification Issues Issue Type: Feature Request Components: Javadoc and API Affects Versions: 1.0 Reporter: Jozef Hartinger Priority: Minor Fix For: 1.1 (Proposed) The spec says {quote}Otherwise, the exception aborts processing of the event. No other observer methods of that event will be called. The BeanManager.fireEvent() or Event.fire() method rethrows the exception. If the exception is a checked exception, it is wrapped and rethrown as an (unchecked) ObserverException.{quote} The JavaDoc for BM.fireEvent() and Event.fire() only mentions IllegalArgumentException. The fact that the ObserverException or any other unchecked exception raised by an observer method should be mentioned. -- 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

4
6
0 / 0

[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-253) Support for @Nonbinding at annotation level

by Pete Muir (JIRA)

Pete Muir created CDI-253: ----------------------------- Summary: Support for @Nonbinding at annotation level Key: CDI-253 URL: https://issues.jboss.org/browse/CDI-253 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Pete Muir Fix For: 1.1 (Proposed) Allow putting @Nonbinding at annotation level on qualifiers to apply to entire qualifier -- 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, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (CDI-138) Allow an extension to register an interceptor bindings with an AnnotatedType

by Kevin Pollet (JIRA)

Allow an extension to register an interceptor bindings with an AnnotatedType ---------------------------------------------------------------------------- Key: CDI-138 URL: https://issues.jboss.org/browse/CDI-138 Project: CDI Specification Issues Issue Type: Feature Request Components: Interceptors, Portable Extensions Affects Versions: 1.0 Reporter: Kevin Pollet Fix For: 1.1 (Proposed) At BeforeBeanDiscovery phase an interceptor binding could be added with an {{AnnotatedType}} instead of annotation class. This could allow to add annotations to existing annotation attributes. For example this case is needed for annotations {{@CacheResult}}, {{@CacheRemoveEntry}} and {{@CacheRemoveAll}} from JSR-107 which haven't annotation attributes annotated with {{@NonBinding}}. The method signature could be: * {{BeforeBeanDiscovery#addInterceptorBinding(AnnotatedType<?> annotatedType, Annotation... bindingTypeDef)}} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

4
13
0 / 0

[JBoss JIRA] Created: (CDI-141) remove overly strict Serialization requirements for @Inject method and ct parameters

by Mark Struberg (JIRA)

remove overly strict Serialization requirements for @Inject method and ct parameters ------------------------------------------------------------------------------------ Key: CDI-141 URL: https://issues.jboss.org/browse/CDI-141 Project: CDI Specification Issues Issue Type: Bug Components: Beans, Resolution Affects Versions: 1.0 Reporter: Mark Struberg Fix For: 1.1 (Proposed) Section 6.6.4 declares that: > If a producer method declares a passivating scope and: > .. > * has a parameter that does not resolve to a passivation capable > dependency, > then the container automatically detects the problem and > treats it as a deployment problem. Something like @Produces @SessionScoped @AutoAuthenticated public User getCurrentUser(MyConfig mc) { return ... (MyConfig is not Serializable and gets produced as @ApplicationScoped) would not be allowed. The same restriction currently applies to parameters of @Inject methods and constructors: >If a managed bean which declares a passivating scope: > has a ... , bean constructor parameter or initializer method parameter > that does not resolve to a passivation capable dependency, ... This maybe comes from simple @Inject setters which set the given method parameters 1:1 into class members. But for all other cases this restriction is just way too rigid. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

3
6
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, 7 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, 7 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, 7 months

2
4
0 / 0

[JBoss JIRA] (CDI-177) Clarify how default bean EL name and @Named qualifier with no value at injection point are related

by Martin Kouba (Created) (JIRA)

Clarify how default bean EL name and @Named qualifier with no value at injection point are related -------------------------------------------------------------------------------------------------- Key: CDI-177 URL: https://issues.jboss.org/browse/CDI-177 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.0 Reporter: Martin Kouba Related CDI 1.0 spec chapters: *2.5.2 Default bean EL names* *3.11 The qualifier @Named at injection points* -- 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, 7 months

4
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev August 2012