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

[ 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. -- This message was sent by Atlassian JIRA (v7.2.3#72005)