October 2017 - cdi-dev - Jboss List Archives

Duplicate javax.annotation packages and Java 9

by John Ament

Hey all Not sure where else to turn 😊 I'm trying to start testing my apps on Java 9, I believe Java 9 kicks back the javax.annotation dependency that CDI declares due to a package collision with the built in JDK's javax.annotation package<https://docs.oracle.com/javase/9/docs/api/javax/annotation/package-summar...>. The errors I get are due to missing javax/annotation/Priority. I'm wondering if anyone else has tried this, and if there's a clean work around? John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

6 years, 12 months

6
10
0 / 0

Consistency across specs with the use of @Priority

by John Ament

I found this interesting to say the least. In CDI, we use highest priority where the value of the @Priority annotation is compared the higher numeric value is considered higher priority. We followed suite so far in MicroProfile specs. I'm not looking to throw dirt, but wanted to get a general opinion from others on this. The JAX-RS treats the lower numeric value as more important (in mathematical terms, it's being treated as the denominator). > If two or more providers are candidates for a certain task, the one with the highest priority is chosen: the highest priority is defined to be the one with the lowest value in this case. That is, @Priority(1) is higher than @Priority(10). So I'm wondering, why did CDI use the approach that CDI is using? John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.

7 years, 2 months

3
2
0 / 0

[JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-712: ---------------------------------- So I've just updated the [test repo|https://github.com/mkouba/alternative-builtin-beans] and both impls still fail (even OWB 2.0.2). > Clarify whether is should be possible to "override" built-in Instance/Provider > ------------------------------------------------------------------------------ > > Key: CDI-712 > URL: https://issues.jboss.org/browse/CDI-712 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.1 (Discussion) > > > In theory, an extension could register an alternative custom bean to override the built-in Instance/Provider bean for injection points such as {{@Inject Provider<String>}}. > It is not forbidden at the moment. The spec only states that there must be a built-in bean eligible for any injection point with Instance/Provider required type and any qualifier. See also https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#builtin_instance. > It seems to be a powerful feature. On the other hand, it might be a source of confusion. Take for example this injection point: > {code:java} > @Inject > @MyQualifier > Instance<String> instance; > {code} > The qualifier is now considered when calling {{instance.get()}} and NOT when resolving the injection point. > Note that the spec already allows to decorate built-in beans. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

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

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-468: -------------------------------- [~mkouba] I'm not sure TBH. I think one way to solve it is to get access to the interceptor binding that caused the current interceptor to be invoked. It shouldn't matter if: - The interceptor binding was added directly to the class OR - It was added programmatically via {{InterceptionFactory}} OR - It was added programmatically via an {{Extension}} OR - It was added via a {{Stereotype}} I would hope it's a seamless experience. I just want the current interceptor binding, and that's all I really need. > 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 > Fix For: 2.1 (Discussion) > > > 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 (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-719) Allow attributes on scope annotations

by Todor Boev (JIRA)

Todor Boev created CDI-719: ------------------------------ Summary: Allow attributes on scope annotations Key: CDI-719 URL: https://issues.jboss.org/browse/CDI-719 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Affects Versions: 2.Future Reporter: Todor Boev Priority: Minor The 2.0 specification states that scope annotations with attributes result in non-portable behavior: https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#defining_new_scope_type At the same time Java EE standards like JSF use attributes on some of their scope annotations.:http://docs.oracle.com/javaee/7/api/javax/faces/flow/FlowSco... There are use cases of applications that have a well defined structure, but the user must specify multiple copies of that structure. One can imagine a server application that must handle multiple endpoints, so the user must have the means to create multiple copies of a request processing pipeline. E.g. {{@RequestScoped("login")}}, {{@RequestScoped("shopping-card")}}. Ideally CDI should use annotation instances, rather than annotation classes to select contexts. http://docs.jboss.org/cdi/api/2.0/javax/enterprise/inject/spi/BeanAttribu... http://docs.jboss.org/cdi/api/2.0/javax/enterprise/inject/spi/BeanManager... http://docs.jboss.org/cdi/api/2.0/javax/enterprise/context/spi/Context.ht... If this is not possible at least BeanAttributes can have a convenience method to get the scope annotation instance, and the specification should explicitly allow the use of attributes on scope annotations. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 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: ---------------------------------- [~meetoblivion] do you think we should provide a different solution for the {{InterceptionFactory}} use case? > 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 > Fix For: 2.1 (Discussion) > > > 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 (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

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

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-468: -------------------------------- [~atijms] has another usecase around this, maybe it deserves its own ticket. When you programmatically add an interceptor to a bean via {{InterceptionFactory}} the actual interceptor binding added gets lost. For similar use cases, when you have a nonbinding attribute the value of that attribute is just completely lost. > 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 > Fix For: 2.1 (Discussion) > > > 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 (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

Interceptor bindings from interceptor when using 2.0 interception factory

by arjan tijms

Hi, Normally a workaround to get the interceptor bindings from within an Interceptor is to inspect the target and/or the injected intercepted bean. However, when adding an interceptor via the new CDI 2.0 interception factory, things become a bit more muddy. See e.g. https://github.com/javaee-samples/javaee8-samples/blob/master/cdi/interce... Weld has the following method to get the bindings from the InvocationContext: Set<Annotation> bindings = (Set<Annotation>) invocationContext.getContextData().get("org.jboss.weld.interceptor.bindings"); But this is obviously non-standard. Is there a standard way to get the bindings? Perhaps getting hold of the Bean<T> that represents the current Interceptor? Kind regards, Arjan Tijms

7 years, 2 months

2
7
0 / 0

[JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-710: ------------------------------------- Fix Version/s: 2.1 (Discussion) > Require default event ExecutorService to be managed on Java EE > -------------------------------------------------------------- > > Key: CDI-710 > URL: https://issues.jboss.org/browse/CDI-710 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Guillermo González de Agüero > Fix For: 2.1 (Discussion) > > > When running on a Java EE environment, CDI should use a managed executor service by default for asynchronous operations. > This is already required by the JAX-RS 2.1 spec (http://download.oracle.com/otndocs/jcp/jaxrs-2_1-pfd-spec/index.html), section 5.8: > {quote}In an environment that supports the Concurrency Utilities for Java EE [13], such as the Java EE Full Profile, implementations MUST use ManagedExecutorService and ManagedScheduledExecutorService, respectively. The reader is referred to the Javadoc of ClientBuilder for more information about executor services.{quote} > Containers will presumably offer monitoring features and thread pool configuration options for managed executor services. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-712: ------------------------------------- Fix Version/s: 2.1 (Discussion) > Clarify whether is should be possible to "override" built-in Instance/Provider > ------------------------------------------------------------------------------ > > Key: CDI-712 > URL: https://issues.jboss.org/browse/CDI-712 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.1 (Discussion) > > > In theory, an extension could register an alternative custom bean to override the built-in Instance/Provider bean for injection points such as {{@Inject Provider<String>}}. > It is not forbidden at the moment. The spec only states that there must be a built-in bean eligible for any injection point with Instance/Provider required type and any qualifier. See also https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#builtin_instance. > It seems to be a powerful feature. On the other hand, it might be a source of confusion. Take for example this injection point: > {code:java} > @Inject > @MyQualifier > Instance<String> instance; > {code} > The qualifier is now considered when calling {{instance.get()}} and NOT when resolving the injection point. > Note that the spec already allows to decorate built-in beans. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2017