May 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] Created: (CDI-132) Clarify which initial info AnnotatedType should contain

by Mark Struberg (JIRA)

Clarify which initial info AnnotatedType should contain ------------------------------------------------------- Key: CDI-132 URL: https://issues.jboss.org/browse/CDI-132 Project: CDI Specification Issues Issue Type: Clarification Reporter: Mark Struberg The spec is not exactly clear about the initial content of AnnotatedType. When initially building the AnnotatedType (e.g. before handing it over to the Extensions) we need to pre-fill them with the info from the annotations from the classes. Should this AnnotatedType: 1.) contain no annotations from superclasses? 2.) contain all annotations from superclasses? 3.) contain @Inherited annotations from superclasses? I think the other questions already got cleared up in CDI-70: Should AnnotatedType contain derived public? protected? private? methods/fields from a superclass? Imo it should contain all information which would be available by manually parsing any annotations. In other words: it should be possible to completely modify or emulate annotations of a parsed type. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

8
26
0 / 0

[JBoss JIRA] Created: (CDI-123) Using Seam XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification

by Richard Hightower (JIRA)

Using Seam XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification ----------------------------------------------------------------------------------------------------------------------------- Key: CDI-123 URL: https://issues.jboss.org/browse/CDI-123 Project: CDI Specification Issues Issue Type: Feature Request Components: Concepts Affects Versions: 1.1 (Proposed) Reporter: Richard Hightower Fix For: 1.1 (Proposed) Using Seam's CDI XML extension for CDI and Candi XML as a guide, let's add the ability to do XML config back into the specification. Annotations and Alternatives should always be the first line of offense for doing injection, decoration and interception. However, there are times when you want to configure things that don't fit well into this model. This is also useful for testing. This is not to give up type safeness via annotations, but to have some additional flexibility. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

8
12
0 / 0

[JBoss JIRA] Created: (CDI-120) Add an optional Portlet specification support

by Mark Struberg (JIRA)

Add an optional Portlet specification support --------------------------------------------- Key: CDI-120 URL: https://issues.jboss.org/browse/CDI-120 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Reporter: Mark Struberg We should mention the portlet specification and how CDI-1.1 should be utilised/supported in a portlet environment. This is an important prerequisite for the JSR-344 EG to deprecate the JSF @javax.faces.bean.ManagedBean capabilities. Imo there is currently no argument which prevents to run a CDI container from running in a portlet environment anyway. No CDI interface imports any javax.servlet.* class. It could affect the wording in 6.5.2. which defines the built in scopes as being 'as defined in the Servlet specification'. We could easily extend this to also cover the portlet definition. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

3
8
0 / 0

[JBoss JIRA] (CDI-203) Decorator support for @MessageDriven bean MessageListener interface

by David Blevins (Created) (JIRA)

Decorator support for @MessageDriven bean MessageListener interface ------------------------------------------------------------------- Key: CDI-203 URL: https://issues.jboss.org/browse/CDI-203 Project: CDI Specification Issues Issue Type: Feature Request Components: Decorators, Java EE integration Affects Versions: 1.1 (Proposed) Reporter: David Blevins Interceptors message-driven beans are explicitly mentioned as supported in CDI 1.0, but decorator support appears to be clearly left out. Decorators that implement the message listener interface would be very useful. As well, most contains have one stack now that does both interceptors and decorators, so enabling this for MDBs would be quite easy. -- 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

12 years, 2 months

4
12
0 / 0

[JBoss JIRA] (CDI-186) Interceptor bindings need clarification

by Jozef Hartinger (Created) (JIRA)

Interceptor bindings need clarification --------------------------------------- Key: CDI-186 URL: https://issues.jboss.org/browse/CDI-186 Project: CDI Specification Issues Issue Type: Clarification Components: Interceptors Affects Versions: 1.1.EDR1 Reporter: Jozef Hartinger Fix For: 1.1.EDR2 As part of CDI-2, changes were made to the Interceptors chapter of the CDI specification. These changes need further clarification: {quote} Interceptor bindings defined on methods may override the interceptor bindings defined on classes. {quote} One way to interpret this is that the set of interceptor bindings defined on a method overrides the set of interceptor bindings defined on a class, which is clearly not the intended behavior. {quote} 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 bean or interceptor must override the *inherited set* by definining an annotation instance of its own, otherwise, the container automatically detects the problem and treats it as a definition error. {quote} Here again I would avoid referencing "the inherited set", since it's not clear what that means, and rather use wording similar to the section 2.4.4 - default scope of a stereotype. -- 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

12 years, 2 months

3
7
0 / 0

[JBoss JIRA] Created: (CDI-127) Add support for annotation scanning of Java enums

by Brian Leathem (JIRA)

Add support for annotation scanning of Java enums ------------------------------------------------- Key: CDI-127 URL: https://issues.jboss.org/browse/CDI-127 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Brian Leathem It would be useful if Java enums were included in the CDI annotation scan. A use case for this is found in the Seam Faces project, where we would like to use annotations on enums for configuration purposes. The annotation would look like: @ViewConfig public enum Pages { ... } It is my understanding that the current CDI specification (1.0) does not require scanning of the enum and will not pick up the @ViewConfig annotation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

4
12
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

12 years, 2 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

12 years, 2 months

5
20
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

12 years, 3 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

12 years, 3 months

3
6
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev May 2012