September 2014 - cdi-dev - Jboss List Archives

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

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-468: ---------------------------------- [~arnelim] Well, it does care, since v1.2 (Java EE 7), see also Chapter 3, "Associating Interceptors using Interceptor Bindings". {quote} Anyway it would be way better, if such method would be located directly in the InvocationContext (and not in a sub-interface) {quote} Agreed. > 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, 7 months

1
0
0 / 0

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

by Arne Limburg (JIRA)

[ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.sy... ] Arne Limburg commented on CDI-468: ---------------------------------- I thought about filing an interceptor spec issue, too. But the interceptor spec does not care about interceptor bindings at all. Anyway it would be way better, if such method would be located directly in the InvocationContext (and not in a sub-interface). > 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, 7 months

1
0
0 / 0

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

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-468: ---------------------------------- Looks like a good idea. We should probably expose the set of all method/constructor interceptor bindings: {code} Collection<Annotation> getInterceptorBindings(); {code} And this set could be empty if there are no bindings declared and only interceptors using the {{@Interceptors}} annotation are associated. Anyway, if we conclude that this is useful and doable we should file a new interceptor spec issue. > 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, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-479) How to identify the bean a static observer method belongs to

by Martin Kouba (JIRA)

Martin Kouba created CDI-479: -------------------------------- Summary: How to identify the bean a static observer method belongs to Key: CDI-479 URL: https://issues.jboss.org/browse/CDI-479 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba Let's sum up some parts of the spec which are relevant to static observer methods: "10.4. Observer methods": {quote} An observer method is a non-abstract method of a managed bean class or session bean class... An observer method may be either static or non-static. {quote} "10.3. Observer resolution": {quote} An event is delivered to an observer method if: * The observer method belongs to an enabled bean. * ... {quote} "12.4.3. Bean discovery": {quote} For each observer method of every enabled bean, the container registers an instance of the ObserverMethod interface defined in The ObserverMethod interface. {quote} Now what is the algorithm to *identify the bean a static observer method belongs to*? Is is bound to all beans whose Bean.getBeanClass() declares the method? There are two special scenarios I have in mind: h3. Static observer method on an abstract class {code:java} public abstract class Foo { public static observe1(@Observes Event1 event1) { } } public class Bar extends Foo { } {code} Foo is not a bean. Foo.observe1() is not a method of managed bean class Bar (if we strictly follow the JSL). Is the observer method detected? Does it belong to Bar? What if there are several subclasses of Foo? h3. Specialization {code:java} public class Foo { public static observe1(@Observes Event2 event2) { } } @Specializes public class Bar extends Foo { } {code} Foo is specialized by Bar and thus it's disabled. Is the observer method detected? Does it belong to Bar? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-47) Add required attribute to <interceptor> tag in beans.xml

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-47?page=com.atlassian.jira.plugin.sys... ] Antoine Sabot-Durand resolved CDI-47. ------------------------------------- Fix Version/s: 1.1.Final (was: TBD) Resolution: Done This feature was resolve with CDI 1.1 and the introduction of {{@Priority}} for interceptor. > Add required attribute to <interceptor> tag in beans.xml > --------------------------------------------------------- > > Key: CDI-47 > URL: https://issues.jboss.org/browse/CDI-47 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 1.1.Final > > > Currently the deployment will fail if an interceptor is not present, which means that it is not conventient to use interceptors from optional modules, as the end user will need to open up the jar file and edit the beans.xml file manually. > Adding a required="true|false" attribute to the <interceptor> element in beans.xml would allow an archive to specify that the interceptor is not essential, and if it is not found it should simply be ignored. > For example, currently Seam Security has a hard dependency on Seam Persistence because it uses the Transaction interceptor, and the deployment will fail if Seam Persistence is not present. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

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

by Antonin Stefanutti (JIRA)

[ https://issues.jboss.org/browse/CDI-469?page=com.atlassian.jira.plugin.sy... ] Antonin Stefanutti commented on CDI-469: ---------------------------------------- [~jharting], indeed, I think that's the general idea. Otherwise stated, the need is to be able to have non {{@Dependent}} producer methods depending on the {{InjectPoint}} and somehow have the resultant produced values _cached_ (i.e. the producer method does not get called twice without the active scope) whenever the {{InjectionPoint}} are _equals_, _equals_ being here defined by qualifiers equality. > 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, 7 months

1
0
0 / 0

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

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-469?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-469: ------------------------------------- My understanding of the usecase is the following: Suppose we have a *binding* qualifier: {code:JAVA} @Qualifier ... public @interface Converter { String value(); } {code} and we want to produce several distinct beans e.g.: @ApplicationScoped @Converter("foo") Function<?,?> @ApplicationScoped @Converter("bar") Function<?,?> We have to write a separate producer method for each, specifying the binding qualifier. We cannot write one producer to produce both foo and bar. We do not however want to duplicate the producer method code. Instead, we would like to direct creation to the single generic method that, should it know the value of @Converter annotation, is capable of creating the bean instance. Something like binding at the injection point side but non-binding at the producer side. > 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, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-279) Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-279?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-279: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Provide CDI SPI that could be used to directly replace java.lang.reflect methods for expanding the use of @Stereotype to Java EE 7 platform > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-279 > URL: https://issues.jboss.org/browse/CDI-279 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Hong Zhang > Assignee: Pete Muir > Fix For: 2.0 (discussion) > > > Please provide CDI SPI that could be used to directly replace the java.lang.reflect methods when expanding the use of @Stereotype to Java EE 7 platform. > Also attaching the relevant sections from Bill's @Stereotype proposal below: > ================================================ > Stereotypes are implemented by CDI, but (typically) the Java EE deployment processing has no knowledge of CDI when it's looking for Java EE annotations. Integrating with CDI so that stereotypes could be considered during this deployment-time annotation processing would require a new CDI SPI. > Many existing implementations would need to be changed to understand > how to expand stereotypes. Requiring every technology to do this > itself will almost certainly lead to inconsistencies. Since stereotypes > are a CDI feature, CDI will provide a simple replacement for the > java.lang.reflect methods such as getAnnotations that takes into > account stereotypes. > Some technologies will not want to have a hard dependency on CDI so > we'll need to provide a simple way for them to conditionally invoke > these new methods only if CDI is present, falling back to java.lang.reflect > if not. This seems straightforward. In this case, the functionality of > @Stereotype would not be available to applications that chose to run > without CDI. > =============================== -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-478) Interceptor and Decorator EPIC for CDI 2.0

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-478?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-478: ------------------------------------- Epic Name: CDI 2 AOP (was: Interceptor and Decorator EPIC for CDI 2.0) > Interceptor and Decorator EPIC for CDI 2.0 > ------------------------------------------ > > Key: CDI-478 > URL: https://issues.jboss.org/browse/CDI-478 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > > This Epic ticket gathers all work and documents about interceptor and decorator in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/10iexiDfMT9tYaUPa2cGiw4P68VG_bryDIS0DK... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (CDI-478) Interceptor and Decorator EPIC for CDI 2.0

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-478?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-478: ------------------------------------- Fix Version/s: 2.0 (discussion) > Interceptor and Decorator EPIC for CDI 2.0 > ------------------------------------------ > > Key: CDI-478 > URL: https://issues.jboss.org/browse/CDI-478 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > This Epic ticket gathers all work and documents about interceptor and decorator in CDI 2.0 > Draft document is here : https://docs.google.com/document/d/10iexiDfMT9tYaUPa2cGiw4P68VG_bryDIS0DK... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2014