September 2014 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-470) Clarify @Vetoed on recursive package

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-470?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-470: ---------------------------------- In my opinion, it is clear that {{@Vetoed}} only applies to the "current package". The spec simply states that the class must be "in a package": {quote} A top-level Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification, or if it meets all of the following conditions: * ... * It is not annotated @Vetoed or in a package annotated @Vetoed. * ... {quote} See also "3.1.1. Which Java classes are managed beans" (and similarly for session beans). AFAIK the Java lang does not define the relation between the package and its subpackages from the visibility point of view, nor provides a Reflection API to work with subpackages. > Clarify @Vetoed on recursive package > ------------------------------------ > > Key: CDI-470 > URL: https://issues.jboss.org/browse/CDI-470 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Affects Versions: 1.2.Final > Reporter: Antonio Goncalves > > It's not clear in the specification is {{@Vetoed}} only apply to the current package or subpackages as well. This has been addressed on [CDI-299] but not solved. Either, we make it clearer in the spec that it only addresses the current package and not subpackages, or we could have a boolean, such as {{recursive}} : > {code:title=package-info.java} > @Vetoed(recursive=true) > package my.parent.package; > import javax.enterprise.inject.Vetoed; > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-470) Clarify @Vetoed on recursive package

by Antonio Goncalves (JIRA)

Antonio Goncalves created CDI-470: ------------------------------------- Summary: Clarify @Vetoed on recursive package Key: CDI-470 URL: https://issues.jboss.org/browse/CDI-470 Project: CDI Specification Issues Issue Type: Clarification Components: Beans Affects Versions: 1.2.Final Reporter: Antonio Goncalves It's not clear in the specification is {{@Vetoed}} only apply to the current package or subpackages as well. This has been addressed on [CDI-299] but not solved. Either, we make it clearer in the spec that it only addresses the current package and not subpackages, or we could have a boolean, such as {{recursive}} : {code:title=package-info.java} @Vetoed(recursive=true) package my.parent.package; import javax.enterprise.inject.Vetoed; {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-469) Allow nonbinding producer methods to have scopes

by John Ament (JIRA)

John Ament created CDI-469: ------------------------------ Summary: Allow nonbinding producer methods to have scopes Key: CDI-469 URL: https://issues.jboss.org/browse/CDI-469 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans, Contexts Affects Versions: 1.2.Final Reporter: John Ament Currently, you cannot have a nonbinding producer method, e.g. one where the annotation is read at runtime, with a scope. This means that repeated injections always happen. It would be better if you could scope the nonbinding producer methods, so that the results were bound, e.g. to a request scope, so that look ups can be done once. The current way to avoid this is to use a holder object with the proper scope. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-248) Provide means to observe a group of qualified events ("Qualifier Inheritance"?)

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-248?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-248: -------------------------------- do you fire customers for any other reason? I'm thinking you can use [EventMetadata|http://docs.jboss.org/cdi/api/1.1/javax/enterprise/inject/s...] to find out if an appropriate qualifier is on there. > Provide means to observe a group of qualified events ("Qualifier Inheritance"?) > -------------------------------------------------------------------------------- > > Key: CDI-248 > URL: https://issues.jboss.org/browse/CDI-248 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Events > Reporter: Jens Schumann > Fix For: 2.0 (discussion) > > > We have been using CDI events for application development quite extensively. For instance we use events to propagate entity lifecycle events (@Created/@Updated/@Deleted Customer customer) or GUI selections (@Selected/@Deselected Customer customer) and implement related business logic in event observers. (e.g. send email for newly created customers, clear cached values on select/deselect/create/update/delete ...). > This works quite well, however we have noticed that especially our JSF Presentation Tier contains lots of observer methods implementing the same behavior for a group of related CDI events. > Example: > {code} > public class XyzBean { > public void onCustomerCreate(@Observes @Created Customer customer) { reset();} > public void onCustomerUpdate(@Observes @Updated Customer customer) { reset();} > public void onCustomerDelete(@Observes @Deleted Customer customer) { reset();} > > } > {code} > Looks ugly, doesn't it? > The above example could be improved if CDI would be able to observe a group of qualified events, e.g. public void onCustomerLifeCycleEvent(@Observes @LifeCycleChange Customer customer) { reset(); } - ignore method and qualifier names for now. > Since Java does not support annotation inheritance grouping could be achieved using "qualified qualifier annotations": > {code} > @Qualifier > public @interface LifeCycleChange > @Qualifier > @LifeCycleChange > public @interface Created > @Qualifier > @LifeCycleChange > public @interface Updated > @Qualifier > @LifeCycleChange > public @interface Deleted > @Qualifier > public @interface SelectionChange > @Qualifier > @SelectionChange > public @interface Selected > @Qualifier > @SelectionChange > public @interface Deselected > {code} > WDYT? Side effects? Problems? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-468) Extend javax.interceptor.InvocationContext

by Arne Limburg (JIRA)

Arne Limburg created CDI-468: -------------------------------- Summary: Extend javax.interceptor.InvocationContext Key: CDI-468 URL: https://issues.jboss.org/browse/CDI-468 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Arne Limburg Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly. I propose to extend the javax.interceptor.InvocationContext interface with a method public Annotation getInterceptorBinding() or public <A extends Annotation> A getInterceptorBinding(Class<A> type) The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-460) Support repeating qualifiers in CDI SPI

by Arne Limburg (JIRA)

[ https://issues.jboss.org/browse/CDI-460?page=com.atlassian.jira.plugin.sy... ] Arne Limburg commented on CDI-460: ---------------------------------- I think, this are two different issues: First: Clarify if adding multiple Annotations of the same type is possible. Second: Add support for Annotation-Lists (like the Costraint.List feature in bean validation). > Support repeating qualifiers in CDI SPI > --------------------------------------- > > Key: CDI-460 > URL: https://issues.jboss.org/browse/CDI-460 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 2.0 (discussion) > Reporter: Antonin Stefanutti > > In CDI 1.2, it is not explicitly stated whether altering the annotation-based metadata in a way to add multiple annotations of the same type is possible or not. That situation occurs with the following combinations: > {{AnnotatedType.getAnnotations()}} and {{ProcessAnnotatedType.setAnnotatedType(AnnotatedType at)}}, > {{BeanAttributes.getQualifiers()}}, and {{ProcessBeanAttributes.setBeanAttributes(BeanAttributes ba)}}, > {{InjectionPoint.getQualifiers}} and {{ProcessInjectionPoint.setInjectionPoint(InjectionPoint ip)}}. > Being able to decorate these metadata with repeating annotations enables powerful and elegant use cases as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004], that is the ability to use an annotation both as a CDI qualifier and a metadata provider during injection. > Given that Java 8 provides support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repea...], it seems logical to have repeating annotations supported at the CDI SPI level. Tough, that's important to have that support explicitly stated and specified in CDI. > Indeed, while Weld permits metadata alteration with repeating annotations, OpenWebBeans does not for the moment though developers understand the need and are willing to open that behavior as discussed in [OWB-1004|https://issues.apache.org/jira/browse/OWB-1004] as long as that support will be made explicit in the specification. > That applies as well for {{EventMetadata.getQualifiers}} in _read-only_. > While that request is technically independent from Java 8, it is correlated to the support of repeating qualifiers in the typesafe resolution mechanism that is likely to be treated as part of the Java 8 stream of the CDI 2.0 specification. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-114) Allow registration of beans at runtime

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-114?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-114: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Allow registration of beans at runtime > -------------------------------------- > > Key: CDI-114 > URL: https://issues.jboss.org/browse/CDI-114 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Vincent Massol > Fix For: 2.0 (discussion) > > > I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-259) Add conversation begin and conversation end events

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-259?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-259: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Add conversation begin and conversation end events > -------------------------------------------------- > > Key: CDI-259 > URL: https://issues.jboss.org/browse/CDI-259 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-270) Allow @WithAnnotations to be applied to other events

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-270?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-270: ------------------------------------------ Not sure to understand. You want to use {{@WithAnnotation}} for other lifecycle events? > Allow @WithAnnotations to be applied to other events > ---------------------------------------------------- > > Key: CDI-270 > URL: https://issues.jboss.org/browse/CDI-270 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.EDR > Reporter: Pete Muir > Labels: with-annotations > Fix For: TBD > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-248) Provide means to observe a group of qualified events ("Qualifier Inheritance"?)

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-248?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-248: ------------------------------------------ Could be interesting to study a way to compose qualifiers for CDI 2.0. and to evaluate this need. > Provide means to observe a group of qualified events ("Qualifier Inheritance"?) > -------------------------------------------------------------------------------- > > Key: CDI-248 > URL: https://issues.jboss.org/browse/CDI-248 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Events > Reporter: Jens Schumann > Fix For: 2.0 (discussion) > > > We have been using CDI events for application development quite extensively. For instance we use events to propagate entity lifecycle events (@Created/@Updated/@Deleted Customer customer) or GUI selections (@Selected/@Deselected Customer customer) and implement related business logic in event observers. (e.g. send email for newly created customers, clear cached values on select/deselect/create/update/delete ...). > This works quite well, however we have noticed that especially our JSF Presentation Tier contains lots of observer methods implementing the same behavior for a group of related CDI events. > Example: > {code} > public class XyzBean { > public void onCustomerCreate(@Observes @Created Customer customer) { reset();} > public void onCustomerUpdate(@Observes @Updated Customer customer) { reset();} > public void onCustomerDelete(@Observes @Deleted Customer customer) { reset();} > > } > {code} > Looks ugly, doesn't it? > The above example could be improved if CDI would be able to observe a group of qualified events, e.g. public void onCustomerLifeCycleEvent(@Observes @LifeCycleChange Customer customer) { reset(); } - ignore method and qualifier names for now. > Since Java does not support annotation inheritance grouping could be achieved using "qualified qualifier annotations": > {code} > @Qualifier > public @interface LifeCycleChange > @Qualifier > @LifeCycleChange > public @interface Created > @Qualifier > @LifeCycleChange > public @interface Updated > @Qualifier > @LifeCycleChange > public @interface Deleted > @Qualifier > public @interface SelectionChange > @Qualifier > @SelectionChange > public @interface Selected > @Qualifier > @SelectionChange > public @interface Deselected > {code} > WDYT? Side effects? Problems? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 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 2014