August 2017 - cdi-dev - Jboss List Archives

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

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.sy... ] 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)

7 years, 4 months

1
0
0 / 0

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

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.sy... ] 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)

7 years, 4 months

1
0
0 / 0

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

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.sy... ] 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)

7 years, 4 months

1
0
0 / 0

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

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.sy... ] 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)

7 years, 4 months

1
0
0 / 0

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

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.sy... ] 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)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (CDI-711) BeanConfigurator cannot be used to define alternative beans enabled for an application

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-711?page=com.atlassian.jira.plugin.sy... ] 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)

7 years, 4 months

1
0
0 / 0

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

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.sy... ] 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)

7 years, 4 months

1
0
0 / 0

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

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.sy... ] 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/ja...] 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)

7 years, 4 months

1
0
0 / 0

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

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.sy... ] 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<X>? > 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<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.2.3#72005)

7 years, 4 months

1
0
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: ---------------------------------- 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<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.2.3#72005)

7 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev August 2017