January 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-292) Drop ProcessModule.getAnnotatedTypes()

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-292?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-292. --------------------------- Resolution: Done Merged > Drop ProcessModule.getAnnotatedTypes() > -------------------------------------- > > Key: CDI-292 > URL: https://issues.jboss.org/browse/CDI-292 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.1.PRD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 1.1.PFD > > > With @WithAnnotations in place it is now possible for extensions to indicate with fine granularity which container lifecycle events it is interested in and thus not to harm performance that much if the CDI implementation is efficient. > Therefore, I don't like the ProcessModule.getAnnotatedTypes() method because: > 1.) There is no granularity. If extensions start to use it inefficiently it will always harm performance heavily. > 2.) I am not convinced this method is needed. It was not present in CDI 1.0. The only benefit of the method is that it allows for an extension to get an idea where a given AnnotatedType is comming from. There are other more efficient ways of exposing the same information. If we really need to do this we should probably introduce an abstraction over a bean archive (e.g. a Module object) and add a getModule() method to ProcessAnnotatedType. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-282) Vetoing types - clarify consequences

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-282?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-282. --------------------------- Resolution: Done Merged > Vetoing types - clarify consequences > ------------------------------------ > > Key: CDI-282 > URL: https://issues.jboss.org/browse/CDI-282 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Pete Muir > Priority: Critical > Fix For: 1.1.PFD > > > The spec currently says {{@Vetoed}} type is *prevented from being considered by CDI* and {{ProcessAnnotatedType.veto()}} forces the container to ignore the type. This is quite obvious for classes and interfaces. However not so clear when vetoing annotations (e.g. qualifier). I think ignoring means not being considered as qualifier (thus affects resolution). Other (rather theoretical) example is vetoing non-contextual instances - should it prevent performing dependency injection? -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-286) Inconsistencies in chapter "Validation of passivation capable beans and dependencies"

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-286?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-286. --------------------------- Assignee: Pete Muir Resolution: Done Merged > Inconsistencies in chapter "Validation of passivation capable beans and dependencies" > ------------------------------------------------------------------------------------- > > Key: CDI-286 > URL: https://issues.jboss.org/browse/CDI-286 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PRD > Reporter: Martin Kouba > Assignee: Pete Muir > Fix For: 1.1.PFD > > > The spec states in 6.6.4. "Validation of passivation capable beans and dependencies": > {quote} > If a bean which declares a passivating scope type, or any stateful session bean, has a decorator or interceptor which is not a > passivation capable dependency, the container automatically detects the problem and treats it as a deployment problem. > {quote} > WRT CDI-136 "If a bean which declares a passivating scope type, or any stateful session bean," should be replaced with: "If a managed bean or stateful session bean which declares a passivating scope". > I'm not sure about the wording _"has a decorator or interceptor which is not a passivation capable dependency"_ because the wording in section 6.6.1. "Passivation capable beans" is _"interceptors and decorators of the bean are passivation capable"_ (passivation capable dependency vs passivation capable). -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-281) ObserverMethod.notify() breaks backwards compatibility

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-281?page=com.atlassian.jira.plugin.sy... ] Pete Muir resolved CDI-281. --------------------------- Resolution: Done Merged > ObserverMethod.notify() breaks backwards compatibility > ------------------------------------------------------ > > Key: CDI-281 > URL: https://issues.jboss.org/browse/CDI-281 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 1.1.EDR > Reporter: Jozef Hartinger > Assignee: Pete Muir > Priority: Blocker > Fix For: 1.1.PFD > > > ObserverMethod.notify(T event, Set<Annotation> qualifiers) has been added post CDI 1.0 as part of CDI-36. > The added method breaks backwards compatibility (an existing 1.0 Extension may be registering an ObserverMethod implementation that would not implement that method, since it is not part of the 1.0 API). > We should probably isolate that method into a subinterface e.g.: > {code:JAVA} > public interface CuriousObserverMethod<T> extends ObservetMethod<T> { > void notify(T event, Set<Annotation> qualifiers); > } > {code} -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-317) review PassivationCapable interface

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-317?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-317: ----------------------------------- That would effectively duplicate the number of needed Bean<?> in a container. And the effect is really the same! > review PassivationCapable interface > ----------------------------------- > > Key: CDI-317 > URL: https://issues.jboss.org/browse/CDI-317 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > Fix For: 1.1 (Proposed) > > > Currently the spec says that only _passivation capable Beans_ must implement the PassivationCapable interface. > But a Bean class could result in both passivation-capable and not-passivation-capable beans. For e.g. a ProducerMethodBean it depends on the scope of the produced instance. For implementing this properly you would need to always need 2 classes for each bean-type. And even worse - often you know only after the all the Bean-building that this very bean is passivation-capable or not. > Thus I suggest to extend the meaning of PassivationCapable#getId() to allow returning *null* if the very bean doesn't support passivation. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-247) It's currently not possible to implement a primitive and wrapping type producer method for the same type

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-247?page=com.atlassian.jira.plugin.sy... ] Pete Muir reopened CDI-247: --------------------------- > It's currently not possible to implement a primitive and wrapping type producer method for the same type > -------------------------------------------------------------------------------------------------------- > > Key: CDI-247 > URL: https://issues.jboss.org/browse/CDI-247 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 1.0, 1.1.EDR > Reporter: Mark Struberg > Assignee: Pete Muir > Fix For: 1.1.PFD > > > I like to implement a producer which can satisfy the following injection points: > {code} > private @Inject @IsFeatureA Boolean featureA; > private @Inject @IsFeatureA boolean featureA; > {code} > Boolean (wrapper type) and boolean (primitive type) used at the same time. > This is currently not allowed by the CDI spec! > 5.2.4. "Primitive types and null values" defines that > "For the purposes of typesafe resolution and dependency injection, primitive types and their corresponding wrapper types in the package java.lang are considered identical and assignable." > In the same paragraph it also states that > "However, if an injection point of primitive type resolves to a bean that may have null values, such as a producer method with a non-primitive return type or a producer field with a non-primitive type, the container automatically detects the prob- lem and treats it as a deployment problem." > This means that I can only have producer methods and fields which have primitive return values and never use their wrapper types if I like to inject into both boolean and Boolean fields. > But if I use the primitive type, then I loose the ability to explicitly return null for those. > Possible solution: > As primitives and their wrapper only can be @Dependent, it would be perfectly possible to e.g. inspect the InjectionPoint and on a primitive type return a default value and for a wrapper type return null. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-317) review PassivationCapable interface

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-317?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-317: ------------------------------- This seems trivial to address with standard java subclassing. > review PassivationCapable interface > ----------------------------------- > > Key: CDI-317 > URL: https://issues.jboss.org/browse/CDI-317 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > Fix For: 1.1 (Proposed) > > > Currently the spec says that only _passivation capable Beans_ must implement the PassivationCapable interface. > But a Bean class could result in both passivation-capable and not-passivation-capable beans. For e.g. a ProducerMethodBean it depends on the scope of the produced instance. For implementing this properly you would need to always need 2 classes for each bean-type. And even worse - often you know only after the all the Bean-building that this very bean is passivation-capable or not. > Thus I suggest to extend the meaning of PassivationCapable#getId() to allow returning *null* if the very bean doesn't support passivation. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-317) review PassivationCapable interface

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-317?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-317: -------------------------- Fix Version/s: 1.1 (Proposed) > review PassivationCapable interface > ----------------------------------- > > Key: CDI-317 > URL: https://issues.jboss.org/browse/CDI-317 > Project: CDI Specification Issues > Issue Type: Bug > Components: Beans > Reporter: Mark Struberg > Fix For: 1.1 (Proposed) > > > Currently the spec says that only _passivation capable Beans_ must implement the PassivationCapable interface. > But a Bean class could result in both passivation-capable and not-passivation-capable beans. For e.g. a ProducerMethodBean it depends on the scope of the produced instance. For implementing this properly you would need to always need 2 classes for each bean-type. And even worse - often you know only after the all the Bean-building that this very bean is passivation-capable or not. > Thus I suggest to extend the meaning of PassivationCapable#getId() to allow returning *null* if the very bean doesn't support passivation. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-271: ------------------------------- Arne, can you write a patch on the spec? I can review and apply then... > Provide a way to inject Event metadata into an observer method > -------------------------------------------------------------- > > Key: CDI-271 > URL: https://issues.jboss.org/browse/CDI-271 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Arne Limburg > Fix For: 1.1 (Proposed) > > > Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members). > Consider the following example: > {code} > @Inject @MyQualifier > Event<MyObject> event; > public void fireEvent(MyObject object, MyTypeValue type) { > event.select(new MyTypeAnnotationLiteral(type)).fire(object); > } > {code} > Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this: > {code} > public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) { > MyType annotation = ip.getAnnotated().getAnnotation(MyType.class); > MyTypeValue value = annotation.value(); > ... > } > {code} -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-289) Clarify what happens if a CDI-scoped stateful session bean is removed due to exception

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-289?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-289: ------------------------------- we're working on it :-) > Clarify what happens if a CDI-scoped stateful session bean is removed due to exception > -------------------------------------------------------------------------------------- > > Key: CDI-289 > URL: https://issues.jboss.org/browse/CDI-289 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java EE integration > Affects Versions: 1.1.PRD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Labels: faq > Fix For: 1.1 (Proposed) > > > {code:JAVA} > @ApplicationScoped > @Stateful > public class Foo { > ... > } > {code} > According to the EJB spec (4.6.2) the instance of Foo will be removed if a method invocation on Foo throws a runtime exception that is not an application exception. CDI should clarify if in that case a new instance of Foo replaces the old instance or whether the clients will keep receiving NoSuchEJBException for the rest of the application lifetime. -- 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, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev January 2013