From issues at jboss.org Wed Aug 2 13:20:00 2017 From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=) Date: Wed, 2 Aug 2017 13:20:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE In-Reply-To: References: Message-ID: Guillermo Gonz?lez de Ag?ero created CDI-710: ------------------------------------------------ Summary: 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 When runnin 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.2.3#72005) From issues at jboss.org Wed Aug 2 13:21:00 2017 From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=) Date: Wed, 2 Aug 2017 13:21:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillermo Gonz?lez de Ag?ero updated CDI-710: --------------------------------------------- Description: 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. was: When runnin 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. > 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 > > 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.2.3#72005) From issues at jboss.org Tue Aug 8 07:52:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Aug 2017 07:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-711) BeanConfigurator cannot be used to define alternative beans enabled for an application In-Reply-To: References: Message-ID: Martin Kouba created CDI-711: -------------------------------- Summary: BeanConfigurator cannot be used to define alternative beans enabled for an application Key: CDI-711 URL: https://issues.jboss.org/browse/CDI-711 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Affects Versions: 2.0 .Final Reporter: Martin Kouba Custom bean implementations may implement {{Prioritized}} interface. There should be probably a {{BeanConfigurator.priority(int priority)}} method. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Aug 8 07:54:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Aug 2017 07:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-711) BeanConfigurator cannot be used to define alternative beans enabled for an application In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-711: ----------------------------- Fix Version/s: 2.1 (Discussion) > BeanConfigurator cannot be used to define alternative beans enabled for an application > --------------------------------------------------------------------------------------- > > Key: CDI-711 > URL: https://issues.jboss.org/browse/CDI-711 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Martin Kouba > Fix For: 2.1 (Discussion) > > > Custom bean implementations may implement {{Prioritized}} interface. There should be probably a {{BeanConfigurator.priority(int priority)}} method. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Aug 8 08:34:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Aug 2017 08:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: Martin Kouba created CDI-712: -------------------------------- Summary: 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 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}}. 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 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.2.3#72005) From issues at jboss.org Tue Aug 8 08:43:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 8 Aug 2017 08:43:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445638#comment-13445638 ] John Ament commented on CDI-712: -------------------------------- BTW, this is a requirement of MP Config 1.0. > 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 > > 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}}. > 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 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.2.3#72005) From issues at jboss.org Tue Aug 8 08:53:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Aug 2017 08:53:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445647#comment-13445647 ] Martin Kouba commented on CDI-712: ---------------------------------- AFAIK the only requirement of MP Config 1.0 is to satisfy a similar injection point: {code:java} @Inject @ConfigProperty(name="myprj.some.dynamic.timeout", defaultValue="100") private javax.inject.Provider timeout; {code} For this you don't need to override the built-in Provider but provide a bean with type {{Long}} and qualifier {{ConfigProperty}}. I don't know details but a simple @Dependent producer method injecting {{Config}} and inspecting the injection point metadata could do the trick. > 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 > > 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}}. > 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 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.2.3#72005) From issues at jboss.org Tue Aug 8 08:56:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Tue, 8 Aug 2017 08:56:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445649#comment-13445649 ] John Ament commented on CDI-712: -------------------------------- Agreed, we can provide a bean of type Long to satisfy this requirement as well. Though its preferable to just provide a Provider. > 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 > > 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}}. > 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 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.2.3#72005) From issues at jboss.org Tue Aug 8 08:58:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Aug 2017 08:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445650#comment-13445650 ] Martin Kouba commented on CDI-712: ---------------------------------- Hm, why is it preferable? > 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 > > 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}}. > 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 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.2.3#72005) From issues at jboss.org Tue Aug 8 09:12:00 2017 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 8 Aug 2017 09:12:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445667#comment-13445667 ] Mark Struberg commented on CDI-712: ----------------------------------- > Hm, why is it preferable? A Long Bean would also work but then it would go through the whole CDI stack for EACH and every invocation! With a custom Provider we can do any direct resolution. Also the spec does NOT state that one cannot provide an Alternative for built-in beans. It should also be very easy for Weld to provide exactly that. Note that it is also important to allow custom implementations of javax.inject.Provider as the Container would otherwise not be able to implement JSR-330 afaict. > 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 > > 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}}. > 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 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.2.3#72005) From issues at jboss.org Tue Aug 8 09:17:00 2017 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 8 Aug 2017 09:17:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445672#comment-13445672 ] Mark Struberg commented on CDI-712: ----------------------------------- See also the following spec paragraph (1.0) {noformat} 5.6.2. The built-in Instance The container must provide a built-in bean...: {noformat} This is just a standard bean otherwise and no special rules apply. So why should one not be able to implement an Alternative for it? This is a perfectly legit use case! > 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 > > 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}}. > 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 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.2.3#72005) From issues at jboss.org Tue Aug 8 09:35:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Aug 2017 09:35:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445688#comment-13445688 ] Martin Kouba commented on CDI-712: ---------------------------------- bq. A Long Bean would also work but then it would go through the whole CDI stack for EACH and every invocation! Not a big deal. bq. Also the spec does NOT state that one cannot provide an Alternative for built-in beans. Agreed. bq. Note that it is also important to allow custom implementations of javax.inject.Provider as the Container would otherwise not be able to implement JSR-330 afaict. I don't understand even a little. bq. This is just a standard bean... It's not standard in the way that it must satisfy all {{Instance}} or {{Provider}} for any legal bean type {{X}} and qualifiers are also handled specially. In other words, the built-in bean must be treated in a special way. > 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 > > 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}}. > 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 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.2.3#72005) From issues at jboss.org Tue Aug 8 09:47:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 8 Aug 2017 09:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445700#comment-13445700 ] Martin Kouba commented on CDI-712: ---------------------------------- Also note that built-in beans must be passivation capable dependencies. > 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 > > 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}}. > 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 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.2.3#72005) From issues at jboss.org Tue Aug 8 13:52:00 2017 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 8 Aug 2017 13:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445877#comment-13445877 ] Mark Struberg commented on CDI-712: ----------------------------------- > Not a big deal. Well, that entirely depends on your performance needs. Do a benchmark. A full bean resolving is about 10.000 more expensive than a simple get on a cache Map. > In other words, the built-in bean must be treated in a special way. No, not at all. It must just be *provided* in a special way. That's all. I mentioned the JSR-330 reference because Provider is not a CDI class at all. It's from atinject. So the CDI spec must not prevent any other usages. > Also note that built-in beans must be passivation capable dependencies. Yes, of course. But I have no clue what this changes regarding to the current topic? > 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 > > 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}}. > 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 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.2.3#72005) From issues at jboss.org Wed Aug 9 04:16:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 9 Aug 2017 04:16:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446102#comment-13446102 ] Martin Kouba commented on CDI-712: ---------------------------------- Ok, so I've created https://github.com/mkouba/alternative-builtin-beans to verify the current state of support for {{Instance}} and {{Event}}. As expected Weld does not support this feature. OWB seems to support this feature but does not work correctly - see also the readme. Note that I did not even try to test alternative custom bean for {{BeanManager}} although there is a "standard" built-in bean. Also note that it's not possible to create a decorator for {{BeanManager}} (explicitly disallowed by spec). Feel free to comment the test repo. bq. Yes, of course. But I have no clue what this changes regarding to the current topic? [~struberg] If you provide a custom bean that is not passivation capable you can easily break existing applications. > 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 > > 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}}. > 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 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.2.3#72005) From issues at jboss.org Mon Aug 14 04:20:00 2017 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 14 Aug 2017 04:20:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448243#comment-13448243 ] Mark Struberg commented on CDI-712: ----------------------------------- Hi [~mkouba] Thanks for the catch with the 'hidden' instance. That is fixed now in the OpenWebBeans trunk. I see that so far most containers do not properly implement this feature, so I agree we should not yet advertise this feature ;) Otoh I think it is perfectly covered by the spec and we should support it in our implementations. We allow a lot of things with the built-in Instance Bean. We even allow to decorate them (it's even in the TCK). So why should it be disallowed to provide an Alternative for Provider? > 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 > > 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}}. > 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 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.2.3#72005) From issues at jboss.org Mon Aug 14 07:33:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 14 Aug 2017 07:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448342#comment-13448342 ] Matej Novotny commented on CDI-710: ----------------------------------- ATM the only async operation in CDI are async events. It seems like a bit of an overkill to enforce this requirement. Besides, what would be the gain? As it stands, you can [define your own executor|https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enterprise/event/NotificationOptions.java#L48] for async event notification so you can even use the one from Concurrency utilities. I might be missing some pieces, but I see no harm in leaving this up to integrator/impl. This way, a CDI implementation can (for instance) provide an SPI through which an integrator will supply the default executor services. So the integrator has the power to choose if Conc. utils suffice, or if they prefer something else. > 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 > > 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.2.3#72005) From issues at jboss.org Mon Aug 14 07:42:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 14 Aug 2017 07:42:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448353#comment-13448353 ] John Ament commented on CDI-710: -------------------------------- +1 to standardize this. Marking it as implementation specific makes no sense. > 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 > > 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.2.3#72005) From issues at jboss.org Mon Aug 14 07:47:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 14 Aug 2017 07:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-711) BeanConfigurator cannot be used to define alternative beans enabled for an application In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448359#comment-13448359 ] Matej Novotny commented on CDI-711: ----------------------------------- Looks like a valid use case we missed. Just thinking whether there wasn't some kind of a problem with defining an enabled alternative this late in the bootstrap process? > BeanConfigurator cannot be used to define alternative beans enabled for an application > --------------------------------------------------------------------------------------- > > Key: CDI-711 > URL: https://issues.jboss.org/browse/CDI-711 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Martin Kouba > Fix For: 2.1 (Discussion) > > > Custom bean implementations may implement {{Prioritized}} interface. There should be probably a {{BeanConfigurator.priority(int priority)}} method. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Aug 14 07:53:01 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 14 Aug 2017 07:53:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448365#comment-13448365 ] Matej Novotny commented on CDI-710: ----------------------------------- Not so sure - if you change this, we are then talking about CDI 2.1. And both impls have to have a solution in place by now. E.g. this might cause unnecessary troubles while giving you no real gain (feel free to enlighten me on the bright sides of standardizing this). > 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 > > 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.2.3#72005) From issues at jboss.org Mon Aug 14 08:01:01 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 14 Aug 2017 08:01:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448378#comment-13448378 ] John Ament commented on CDI-710: -------------------------------- As the reporter notes, its to mandate that you're using the ManagedExecutor provided by the container if none is specified by the caller. Right now in OWB, they're relying on ForkJoinPool.commonPool() to do the work, which is an odd default choice. Weld has a property I believe which makes sense, and of course in OWB you can override it via properties if you need to. > 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 > > 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.2.3#72005) From issues at jboss.org Mon Aug 14 08:22:00 2017 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 14 Aug 2017 08:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448400#comment-13448400 ] Romain Manni-Bucau commented on CDI-710: ---------------------------------------- What about deprecating the default executor usage? Sounds like whatever implementations do it will always have a bad guess of the app expectations so it is an API to avoid anyway. It would also solve this ticket making it aligned in EE environments. > 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 > > 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.2.3#72005) From issues at jboss.org Mon Aug 14 08:29:01 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 14 Aug 2017 08:29:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448411#comment-13448411 ] Martin Kouba commented on CDI-710: ---------------------------------- bq. What about deprecating the default executor usage? Sounds like whatever implementations do it will always have a bad guess of the app expectations so it is an API to avoid anyway. It would also solve this ticket making it aligned in EE environments. -10 * we don't have any "exact numbers" about expectations and usage * CDI 2 is also targeted to other environments, not only Java EE > 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 > > 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.2.3#72005) From issues at jboss.org Mon Aug 14 08:50:01 2017 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 14 Aug 2017 08:50:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448442#comment-13448442 ] Romain Manni-Bucau commented on CDI-710: ---------------------------------------- {quote} * we don't have any "exact numbers" about expectations and usage * CDI 2 is also targeted to other environments, not only Java EE {quote} Well this API hurts in most cases: - EE (this ticket) - standalone: if you use that as a bus backbone you need a custom pool, if you use it in a lib then you need a custom pool to ensure you can integrate in any app and don't get any contention between the users of that API and that you can scale, if you use it in an application relying on the bus at runtime then you need to ensure you control it, don't lock it and can tune it. Only case you can use a default executor is when you don't care at all of the behavior of the application in that area which is likely either a very rare user of that API or a completely "offline" application (like a daemon or batch). Issue is really unrelated to EE but to the lack of expectation in term of runtime and the merge of all the asynchronism usages in a single pool (which can lead to locks BTW if the pool is a fixed sized one with a size of queue > 0). This doesn't sound safe enough to be encourage and I don't think it can be solved at stack level since it depends too much the consumer so we should be able to either let the application modify the default executor itself very easily (through an extension or supporting to override it with a Bean) or we should probably deprecate this abusive API. > 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 > > 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.2.3#72005) From issues at jboss.org Mon Aug 14 09:25:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 14 Aug 2017 09:25:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448487#comment-13448487 ] Matej Novotny commented on CDI-710: ----------------------------------- [~meetoblivion] I agree that {{ForkJoinPool.commonPool()}} is a weird choice for EE environment. But that's not really a reason for enforcing a default one, is it? Leaving it up to integrator works just as well plus it can be tweaked and optimized. I wonder if OWB default choice isn't more like an "absolutely last resort" if you fail to specify other executor? [~rmannibucau] I think this ticket is more EE-oriented and what you describe are options for standalone mode (SE?), right? But then again, in SE, you would be probably just fine with {{ForkJoinPool}} not to mention you still can use your own tweaked executor and use {{NotificationOptions}} to enforce it. I don't really see the big problem there and I think calling the API "abusive" is a bit harsh and misplaced. > 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 > > 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.2.3#72005) From issues at jboss.org Mon Aug 14 09:34:00 2017 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 14 Aug 2017 09:34:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448510#comment-13448510 ] Romain Manni-Bucau commented on CDI-710: ---------------------------------------- [~manovotn] didn't want to hurt anyone but literally was impossible to use in any app or PoC I did based on CDI 2.0 and can't think to real use cases - but demos - where dropping this API would hurt. About OWB and ForkJoinPool.commonPool: the only reason it is used is to not create a dedicated pool by default (in standalone and EE) and try to just reuse what is here for low async usage (but true it assumes this pool will be used). In Servlet/EE case you add the fact the config would be highly vendor specific and not controllable JVM wide then commonPool was not a that bad choice for the default - at least as bad as a custom one. > 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 > > 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.2.3#72005) From issues at jboss.org Mon Aug 14 15:40:00 2017 From: issues at jboss.org (Martin Andersson (JIRA)) Date: Mon, 14 Aug 2017 15:40:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-708) Serialization problems in section "1.3.1. JSF example". In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448697#comment-13448697 ] Martin Andersson commented on CDI-708: -------------------------------------- Actually #2, I think I was wrong when it comes to the {{EntityManager}}. The CDI spec defines this guy as a "passivate capable dependency" as long as he was looked up through a CDI producer field. More details: https://stackoverflow.com/a/45681747 > Serialization problems in section "1.3.1. JSF example". > ------------------------------------------------------- > > Key: CDI-708 > URL: https://issues.jboss.org/browse/CDI-708 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 2.0 .Final > Reporter: Martin Andersson > > Section "1.3.1. JSF example" provide an example of a class {{Login}}, that saves in its state an {{EntityManager}} reference and two {{Parameter}} references. > The JPA specification does not say that a {{Parameter}} instance is serializable. > This is also true for the {{EntityManager}} reference which is {{@Dependent}} (see section "1.3.3. Java EE component environment example"). JPA does not specify that the {{EntityManager}} is serializable and the EJB specification only specifies serialization semantics for passivation-enabled {{@Stateful}} EJB:s (which encourages the bean provider to not mark an {{EntityManager}} reference as transient, see EJB ?4.2.1). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Aug 17 04:49:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 17 Aug 2017 04:49:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-711) BeanConfigurator cannot be used to define alternative beans enabled for an application In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448359#comment-13448359 ] Matej Novotny edited comment on CDI-711 at 8/17/17 4:48 AM: ------------------------------------------------------------ Looks like a valid use case we missed. -Just thinking whether there wasn't some kind of a problem with defining an enabled alternative this late in the bootstrap process?- EDIT: Shouldn't cause any troubles as it is really just a twist on a custom bean with {{@Prioritized}}. Also, how about adding another method which would allow you to declare the bean as alternative while selecting it at the same time - {{alternativeWithPriority(int priority)}}? was (Author: manovotn): Looks like a valid use case we missed. Just thinking whether there wasn't some kind of a problem with defining an enabled alternative this late in the bootstrap process? > BeanConfigurator cannot be used to define alternative beans enabled for an application > --------------------------------------------------------------------------------------- > > Key: CDI-711 > URL: https://issues.jboss.org/browse/CDI-711 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Martin Kouba > Fix For: 2.1 (Discussion) > > > Custom bean implementations may implement {{Prioritized}} interface. There should be probably a {{BeanConfigurator.priority(int priority)}} method. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 18 03:59:00 2017 From: issues at jboss.org (Scott Stark (JIRA)) Date: Fri, 18 Aug 2017 03:59:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-713) Why can't Provider injection points use non-proxyable types with @RequestScoped providers? In-Reply-To: References: Message-ID: Scott Stark created CDI-713: ------------------------------- Summary: Why can't Provider injection points use non-proxyable types with @RequestScoped providers? Key: CDI-713 URL: https://issues.jboss.org/browse/CDI-713 Project: CDI Specification Issues Issue Type: Clarification Components: Portable Extensions, Resolution Affects Versions: 1.2.Final Environment: WildflySwarm 2017.7.0 and Weld 2.4.3.Final. Reporter: Scott Stark In looking into the use of javax.inject.Provider wrapped injection point values when dealing with @RequestScoped producers: {code:java} @Inject @Claim(standard = Claims.iat) private Provider providerIAT; {code} {code:java} @Produces @Claim(standard = Claims.iat) @RequestScoped Long getIAT() { JsonWebToken jwt = getJWTPrincpal(); if (jwt == null) { System.out.printf("getIAT, null JsonWebToken\n"); return null; } System.out.printf("getIAT\n"); return jwt.getIssuedAtTime(); } {code} I ran into the following exception: {noformat} Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437: Bean type class java.lang.Long is not proxyable because it is final - {2}. at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:218) at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:182) at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:144) at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:242) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:736) at org.jboss.weld.bean.builtin.InstanceImpl.getBeanInstance(InstanceImpl.java:189) at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:100) at org.eclipse.microprofile.jwt.test.jaxrs.RolesEndpoint.getInjectedIssuer(RolesEndpoint.java:269) {noformat} The spec is not really clear on why this should happen as the javax.inject.Provider is a proxy for the underlying type. It seems to me that this should be allowed, and that the exception I'm seeing from Weld-2.4.3.Final is a bug, but I wanted to get a clarification on why this might be disallowed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 18 04:25:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 18 Aug 2017 04:25:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-713) Why can't Provider injection points use non-proxyable types with @RequestScoped providers? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451160#comment-13451160 ] Martin Kouba commented on CDI-713: ---------------------------------- No, this is not allowed. {{Long getIAT()}} represents a producer method (i.e. bean) and has a normal scope ({{@RequestScope}}). And for an injection point that resolves to a normal scoped bean a client proxy must be injected. For this reason the required bean type must be proxyable. If the given bean type ({{Long}} in this case) cannot be proxied by the container, the container must throw an {{UnproxyableResolutionException}}. Note that the same rules apply to regular injection and programmatic lookup. See also [Client proxies|https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#client_proxies], [Unproxyable bean types|https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#unproxyable] and [The Instance interface|https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#dynamic_lookup]. > Why can't Provider injection points use non-proxyable types with @RequestScoped providers? > --------------------------------------------------------------------------------------------- > > Key: CDI-713 > URL: https://issues.jboss.org/browse/CDI-713 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions, Resolution > Affects Versions: 1.2.Final > Environment: WildflySwarm 2017.7.0 and Weld 2.4.3.Final. > Reporter: Scott Stark > > In looking into the use of javax.inject.Provider wrapped injection point values when dealing with @RequestScoped producers: > {code:java} > @Inject > @Claim(standard = Claims.iat) > private Provider providerIAT; > {code} > {code:java} > @Produces > @Claim(standard = Claims.iat) > @RequestScoped > Long getIAT() { > JsonWebToken jwt = getJWTPrincpal(); > if (jwt == null) { > System.out.printf("getIAT, null JsonWebToken\n"); > return null; > } > System.out.printf("getIAT\n"); > return jwt.getIssuedAtTime(); > } > {code} > I ran into the following exception: > {noformat} > Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437: Bean type class java.lang.Long is not proxyable because it is final - {2}. > at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:218) > at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:182) > at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:144) > at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:242) > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:736) > at org.jboss.weld.bean.builtin.InstanceImpl.getBeanInstance(InstanceImpl.java:189) > at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:100) > at org.eclipse.microprofile.jwt.test.jaxrs.RolesEndpoint.getInjectedIssuer(RolesEndpoint.java:269) > {noformat} > The spec is not really clear on why this should happen as the javax.inject.Provider is a proxy for the underlying type. It seems to me that this should be allowed, and that the exception I'm seeing from Weld-2.4.3.Final is a bug, but I wanted to get a clarification on why this might be disallowed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 18 06:20:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 18 Aug 2017 06:20:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-713) Why can't Provider injection points use non-proxyable types with @RequestScoped providers? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451240#comment-13451240 ] Martin Kouba commented on CDI-713: ---------------------------------- A simple solution for the use case above might be something like: {code:java} @RequestScoped class IssuedAtTimeProducer { Long issuedAtTime; @PostConstruct void init() { JsonWebToken jwt = getJWTPrincpal(); if (jwt == null) { issuedAtTime = null; } issuedAtTime = jwt.getIssuedAtTime(); } @Produces @Claim(standard = Claims.iat) Long getIAT() { return issuedAtTime; } } {code} By the way, a producer method must have scope {{@Dependent}} if it sometimes returns {{null}} (otherwise {{IllegalProductException}} is thrown). > Why can't Provider injection points use non-proxyable types with @RequestScoped providers? > --------------------------------------------------------------------------------------------- > > Key: CDI-713 > URL: https://issues.jboss.org/browse/CDI-713 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions, Resolution > Affects Versions: 1.2.Final > Environment: WildflySwarm 2017.7.0 and Weld 2.4.3.Final. > Reporter: Scott Stark > > In looking into the use of javax.inject.Provider wrapped injection point values when dealing with @RequestScoped producers: > {code:java} > @Inject > @Claim(standard = Claims.iat) > private Provider providerIAT; > {code} > {code:java} > @Produces > @Claim(standard = Claims.iat) > @RequestScoped > Long getIAT() { > JsonWebToken jwt = getJWTPrincpal(); > if (jwt == null) { > System.out.printf("getIAT, null JsonWebToken\n"); > return null; > } > System.out.printf("getIAT\n"); > return jwt.getIssuedAtTime(); > } > {code} > I ran into the following exception: > {noformat} > Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437: Bean type class java.lang.Long is not proxyable because it is final - {2}. > at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:218) > at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:182) > at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:144) > at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:242) > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:736) > at org.jboss.weld.bean.builtin.InstanceImpl.getBeanInstance(InstanceImpl.java:189) > at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:100) > at org.eclipse.microprofile.jwt.test.jaxrs.RolesEndpoint.getInjectedIssuer(RolesEndpoint.java:269) > {noformat} > The spec is not really clear on why this should happen as the javax.inject.Provider is a proxy for the underlying type. It seems to me that this should be allowed, and that the exception I'm seeing from Weld-2.4.3.Final is a bug, but I wanted to get a clarification on why this might be disallowed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Aug 18 11:54:00 2017 From: issues at jboss.org (Scott Stark (JIRA)) Date: Fri, 18 Aug 2017 11:54:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-713) Why can't Provider injection points use non-proxyable types with @RequestScoped providers? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451497#comment-13451497 ] Scott Stark commented on CDI-713: --------------------------------- Ok, so that solution is a possibility I'll explore, but since the injection type has already introduced a proxyable type by using the Provider type, I'm not understanding why it cannot be matched up to a producer method like that shown previously: {code:java} @RequestScoped @Produces @Claim(standard = Claims.iat) Long getIAT() { return ...; } {code} Why is this fundamentally different than wrapping the issuedAtTime value in an @RequestScoped bean? > Why can't Provider injection points use non-proxyable types with @RequestScoped providers? > --------------------------------------------------------------------------------------------- > > Key: CDI-713 > URL: https://issues.jboss.org/browse/CDI-713 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions, Resolution > Affects Versions: 1.2.Final > Environment: WildflySwarm 2017.7.0 and Weld 2.4.3.Final. > Reporter: Scott Stark > > In looking into the use of javax.inject.Provider wrapped injection point values when dealing with @RequestScoped producers: > {code:java} > @Inject > @Claim(standard = Claims.iat) > private Provider providerIAT; > {code} > {code:java} > @Produces > @Claim(standard = Claims.iat) > @RequestScoped > Long getIAT() { > JsonWebToken jwt = getJWTPrincpal(); > if (jwt == null) { > System.out.printf("getIAT, null JsonWebToken\n"); > return null; > } > System.out.printf("getIAT\n"); > return jwt.getIssuedAtTime(); > } > {code} > I ran into the following exception: > {noformat} > Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437: Bean type class java.lang.Long is not proxyable because it is final - {2}. > at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:218) > at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:182) > at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:144) > at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:242) > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:736) > at org.jboss.weld.bean.builtin.InstanceImpl.getBeanInstance(InstanceImpl.java:189) > at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:100) > at org.eclipse.microprofile.jwt.test.jaxrs.RolesEndpoint.getInjectedIssuer(RolesEndpoint.java:269) > {noformat} > The spec is not really clear on why this should happen as the javax.inject.Provider is a proxy for the underlying type. It seems to me that this should be allowed, and that the exception I'm seeing from Weld-2.4.3.Final is a bug, but I wanted to get a clarification on why this might be disallowed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Aug 21 03:24:01 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 21 Aug 2017 03:24:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-713) Why can't Provider injection points use non-proxyable types with @RequestScoped providers? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451730#comment-13451730 ] Matej Novotny commented on CDI-713: ----------------------------------- The {{Provider}} is not the actual type you create proxy from, therefore it doesn't matter if it's proxyable. The rules of proxyability apply to {{Long}} here. {{Provider//Instance}} is more of a holder, allowing you to delay injection and have greater control over it at runtime. It's not meant as "proxyable wrapper". > Why can't Provider injection points use non-proxyable types with @RequestScoped providers? > --------------------------------------------------------------------------------------------- > > Key: CDI-713 > URL: https://issues.jboss.org/browse/CDI-713 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions, Resolution > Affects Versions: 1.2.Final > Environment: WildflySwarm 2017.7.0 and Weld 2.4.3.Final. > Reporter: Scott Stark > > In looking into the use of javax.inject.Provider wrapped injection point values when dealing with @RequestScoped producers: > {code:java} > @Inject > @Claim(standard = Claims.iat) > private Provider providerIAT; > {code} > {code:java} > @Produces > @Claim(standard = Claims.iat) > @RequestScoped > Long getIAT() { > JsonWebToken jwt = getJWTPrincpal(); > if (jwt == null) { > System.out.printf("getIAT, null JsonWebToken\n"); > return null; > } > System.out.printf("getIAT\n"); > return jwt.getIssuedAtTime(); > } > {code} > I ran into the following exception: > {noformat} > Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437: Bean type class java.lang.Long is not proxyable because it is final - {2}. > at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:218) > at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:182) > at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:144) > at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:242) > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:736) > at org.jboss.weld.bean.builtin.InstanceImpl.getBeanInstance(InstanceImpl.java:189) > at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:100) > at org.eclipse.microprofile.jwt.test.jaxrs.RolesEndpoint.getInjectedIssuer(RolesEndpoint.java:269) > {noformat} > The spec is not really clear on why this should happen as the javax.inject.Provider is a proxy for the underlying type. It seems to me that this should be allowed, and that the exception I'm seeing from Weld-2.4.3.Final is a bug, but I wanted to get a clarification on why this might be disallowed. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From arjan.tijms at gmail.com Mon Aug 21 07:45:50 2017 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 21 Aug 2017 13:45:50 +0200 Subject: [cdi-dev] Interceptor bindings from interceptor when using 2.0 interception factory Message-ID: 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/interception-factory/src/main/java/org/javaee8/cdi/interception/factory/MyGreetingProducer.java#L34 Weld has the following method to get the bindings from the InvocationContext: Set bindings = (Set) 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 that represents the current Interceptor? Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170821/d3e85bfe/attachment.html From mkouba at redhat.com Mon Aug 28 03:41:07 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 28 Aug 2017 09:41:07 +0200 Subject: [cdi-dev] Interceptor bindings from interceptor when using 2.0 interception factory In-Reply-To: References: Message-ID: Hi Arjan, comments inline... Dne 21.8.2017 v 13:45 arjan tijms napsal(a): > 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/interception-factory/src/main/java/org/javaee8/cdi/interception/factory/MyGreetingProducer.java#L34 > > > Weld has the following method to get the bindings from the > InvocationContext: > > Set bindings = (Set) > invocationContext.getContextData().get("org.jboss.weld.interceptor.bindings"); In fact, a more safe way is to use the Weld API, cast the invocation context to org.jboss.weld.interceptor.WeldInvocationContext and use the appropriate methods. > > But this is obviously non-standard. Yes. There is already a spec issue: https://issues.jboss.org/browse/CDI-468 but this would require a change in interceptors spec. > > Is there a standard way to get the bindings? Perhaps getting hold of the > Bean that represents the current Interceptor? You can inject a bean with scope @Dependent, qualifier @Default and type Interceptor into any interceptor instance. However, this will not help for @Nonbinding value members of an interceptor binding. > > Kind regards, > Arjan Tijms > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic