What I think would be even better is to see this implemented in the impls (Weld & OWB) and see how users use it, in a release that's not plastered with Alpha or Experimental all over it. While I think we were all wary about it, we need real end user input from the impl standpoint to figure out what makes sense to standardize on. John On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman <reza_rahman(a)lycos.com&gt; wrote:

On Sun, Mar 6, 2016 at 12:25 PM Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: There seems to be a general misunderstanding about how the specs are intended to work. You standardize on things that as a group everyone has agreed would work in a specific way. Right now, the CDI EG is innovating and standardizing on those innovations instead of standardizing on the features already available in the various impls. Lets take a few examples of where impls deviate from the specs. - Bean Validation: Hibernate Validator has a suite of built in validations https://github.com/hibernate/hibernate-validator/tree/master/engine/src/m... - these constraints can in theory work in any pluggable environment, but come with their core engine built in, for people to leverage. These are good targets to leverage in the core spec when its seen as being very useful. - JAX-RS : All of the implementations had client impls paired up with their 1.1 compliant releases, even though it wasn't required. Why? Because it made a ton of sense. Then see what happened afterwards, the EG came together and standardized on a Client API that took a lot of the great features in each impl and made them consistent. - EJB: Lets not forget that the removal of home/remote/local interfaces came from a combination of xdoclet and spring. The EG came together, saw that what was in use and figured out how to standardize on it once the language features were available. - Singleton EJBs: An extension of EJB 3, most vendors supported a form of singleton in their EJBs, and the EJB EG agreed upon it in addition to some concurrency issues that had to be addressed. - CDI: Lets not forget about the hard work people like strub have put into making CDI work well. Scoped Beans only? Awesome idea. https://github.com/apache/openwebbeans/commit/3b3640e17c88e7c095563337194... He didn't wait for the EG to standardize on anything before implementing. - JPA: Lets not forget that HIbernate supports in dual hierarchies the EntityManager and Session interfaces concurrently. Want to use HQL in your @NamedQuery? Sure, it works fine. Bottom line, we need to get these features out into the wild, let people play and come back with input on the various impls. There's nothing stopping the weld team from introducing org.jboss.weld.events.api.AsyncEvent that supports CompletableFuture and CompletionStage, allowing app developers to consume this via an injection point just like Event works today, @Inject AsyncEvent<Foo>. Even if thats not the spec compliant way to do it long term, it makes it clear that you're using a provider specific API. In addition, there would be nothing stopping either team from introducing support for @Priority on observer methods. There's no API change, no spec change required. The spec doesn't mandate that it works, but there's nothing stopping your impl from allowing it. The spec doesn't say you absolutely cannot leverage it. John

Come on Martin, don’t be unfair. How long has this been discussed? Read the original ticket and discussions for bean-discovery-mode where I explained it already. That was almost 4 years ago. But instead the ‚annotated‘ mode got favoured and as it turned out is not that useful in real world because it messes up most Extensions. Can we please do it RIGHT now? What’s the problem? LieGrue, strub

John, I partially disagree with you here. CDI innovated from the beginning. When the project started in 2007 there wasn't any strong typed DI framework around. No spec proposed a SPI like CDI and eventing system in DI framework were inexistant or nearly unused (Who eared of event bus in Spring ?). Following your definition of what is a specification CDI wouldn't be here today. The challenge is to find a real balance between innovating (but not to much and without breaking backward compatibility) and take working ideas around in impl or other framework (like builders from DeltaSpike or Weld bootstrap API that we are about to propose to complete SE API) The problem with CDI, is that it's still limited to Java EE so you'll only have very few user giving you feedback on impl specific features. It will probably change when we'll add SE support but in the meantime we should try to deliver something useful for our users and something they asked (like async events). As I said in my previous mail, Spec annexe can be used to put features that didn't gather enough truct from the EG to be specified. It's a step between spec and impl. Bean validation already done that in 1.0 with method validation http://beanvalidation.org/1.0/spec/#appendix-methodlevelvalidation And standardize it in 1.1 after having gathered users feedback: http://beanvalidation.org/1.1/spec/#d0e267 Antoine Le dim. 6 mars 2016 à 18:41, John D. Ament <john.d.ament(a)gmail.com&gt; a écrit :

2016-03-07 13:57 GMT+01:00 John D. Ament <john.d.ament(a)gmail.com&gt;: Sadly it is like that and guess will stay cause spec are used for standards and any innovation doesn't make users happy if at programming level (it is on ops side) - and believe me I say it after having tried very hard the other way around. That's the way which works the best: you do something outside spec umbrella (including "official implementations") then you standardize it. DeltaSpike is a good example of it: no impl shadow but new proposals which could be standardized as Seam has been.

I agree that it's a sorely missing feature. Jumping in to how to standardize it is how we got into this problem. From what I remember it was agreed to use the lowest entry point. On Mar 6, 2016 12:51, "Reza Rahman" <reza_rahman(a)lycos.com&gt; wrote:

On the flip side, it seems like CompletionStage isn't quite a complete API, and if external callers can only leverage a specific impl then its more of a case where the interface does not enough. John On Sun, Mar 6, 2016 at 1:48 PM Reza Rahman <reza_rahman(a)lycos.com&gt; wrote:

Hi guys, Back from vacation, I'm "happy" to see that we go back on Async event feature (which took us 6 months). @Reza and @Romain sorry but I don't get it. the good practice is to develop for interface (that's why CDI uses Set and not HashSet for instance). I'm ok it's the theory, but if you want to make an exception to this practice you need to have a good reason. So if you want to rely on JDK classes like CompletableFuture instead of interface, you'll probably have to go a step further than that. CompletionStage has a toCompletableFuture() method. To go back to the big picture, as some people around don't seem to be happy with what we designed, we still have the solution to move async event can in specification annexe. It's a solution to test a feature without definitely specifying it. Antoine Le lun. 7 mars 2016 à 08:42, Martin Kouba <mkouba(a)redhat.com&gt; a écrit :

Sent from my iPhone

If you don't understand why most developers would simply expect to use CompletableFuture and would immediately be confused if they see something else, I think we are in bigger trouble than I thought. You should really ask a few developers outside your immediate network or do a Google search to see just how much more prominent CompletableFuture is as oppose to CompletionStage. Not finding a way to use that API and choosing an obscure superclass is a sure recipe for problems.

Already explained what the issue is. This is a usability hazard.

Le 7 mars 2016 08:35, "Martin Kouba" <mkouba(a)redhat.com&gt; a écrit : toCompletableFuture(), i.e. in Weld 3: Yes but it is not natural to convert it IMO = we can do better event2.fireAsync(...).toCompletableFuture()) > AFAIK the default async execution facility of CompletableFuture is ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the CompletionStage interface allows us to wrap the async calls without the specified executor (e.g. CompletionStage.thenApplyAsync(Function<? super T, ? extends U>)) and supply a default one provided by the impl. Should use the pool in which the evznt is fired then "then step" is synchronous is my sample so all is decided at fire time >>> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <http://rmannibucau.wordpress.com> | Github >> <https://github.com/rmannibucau> | LinkedIn >> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >> <http://www.tomitribe.com>>>>> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)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 > Software Engineer > Red Hat, Czech Republic

2016-03-07 9:07 GMT+01:00 Martin Kouba <mkouba(a)redhat.com&gt;: was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). That said I agree on the state switching the pool is better but with these 2 notes: - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml)

2016-03-07 10:57 GMT+01:00 Martin Kouba <mkouba(a)redhat.com&gt;: Why? Typically if you take @Asynchronous (EJB spec) you have already this issue and this is often avoided when portability matters for that particular reason you don't know how you will behave. Or do you think concurrency-utilities solves it?

2016-03-07 11:17 GMT+01:00 Martin Kouba <mkouba(a)redhat.com&gt;: "it will be async" <- then container is free to have a single thread (would make a js impl possible :)) which would totally break you app which is supposed to be scalable. Also if the config is container dependent you can just not be able to configure it - I know the container would be bad but you don't always choose it. In any case not having a config means the feature is not reliable and depending on the container specific features means you are aside the EE goals of reliability in the time IMHO. Also the container opitmizations can have side effects so if not behaving as expected it needs to be spec-ed. Threading model is something central when it starts to be used for a bit mroe than fire and forget once a day, ignoring it is killing before the birth the API you can add on top of it IMO.

2016-03-07 14:15 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: Cause there are several libs where you don't control the pool and the best you can do is to wrap the task (Runnable) on your side. Also you can hit it in background threads you can't enforce to use concurrency spec and finally you can hit it in fully synchronous way if you execute after the CDI chain - which is allowed by CDI and TCK-ed so you can need a way to stack the context to reuse some part after. Last "?": JTA integration: you can also hit it to save data after @TransactionScoped for audit purposes.

2016-03-07 14:34 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: Both cases I'm for this standardization - even if just a subset of vendors config but the minimum to ensure an app can scale on all servers. The bad thing is when the feature is central or important for an app. Then you hide a proprietary feature behind a standard API, this is very nasty and can lead to broken usages pretty easily. However my last point is: even if you fix it for the container you still have the app use cases where the pool are sometimes hidden in apps themself and EE concurrency doesn't help there (and just taking few remote libs it is not rare at all).

2016-03-07 14:47 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: Solutions: 1. standardize the basic pool configs 2. add an API to control the context and its propagation cleanly 3. (i don't know about the tck part so this is a maybe) fix/enhance the integration between concurrency and cdi specs if needed (TCK) + add a way to propagate a context (maybe with concurrency utility proxy factory and a new option in method signature) About proprietary config: yes this is generally bad to rely on it too much for internals of an app. A thread pool is an internal of an app - understand it as opposed to "a MySQL/Oracle datasource".

2016-03-07 16:03 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: To share the idea: ContextView view= beanManager.createContextView(RequestScoped.class); new Runnable() { public void run() { ContextView old = beanManager.restore(RequestScoped.class, view); try { // work } finally { beanManager.restore(RequestScoped.class, old); } } }; Yep I'm for.

Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. Basically this means CompletableFutures are already pretty Java EE ready. If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected?

Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API. As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures? Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API.

Responses in-line. Correct. Why would this matter to the average business code developer? All this would run from managed executors of some kind or the other anyway... Again, why does it matter really? The observer threads themselves should be running from a managed pool that is smart enough to preserve context anyway? If the business developer cares about preserving context in their code, they can use a managed executor themselves on the returned CompletableFuture. I don't follow. Whichever executor service you would use, ultimately there are at least three different threads associated here in all cases. You mean using the same executor? Why does this matter really? They are all managed executors anyway. At best it's reducing one method parameter.

Responses in-line. Sent from my iPhone For framework developers usability is hardly a concern. If they need to preserve their own context they can simply pass in their own managed executor to both the observer thread and the CompletableFuture. In the end, the primary focus should be the masses that we hope will adopt CDI into their applications. Making things harder for them to achieve some limited SPI goal is pretty dangerous. There is no such thing as context propagation outside of EE managed executors. In SE land, the only thing you have is manually writing your own executor to do the same things. These folks will have to pass around their own executors anyway, even to the observer thread.

Side note: this is still true for CompletionStage. Le 7 mars 2016 22:48, "Reza Rahman" <reza_rahman(a)lycos.com&gt; a écrit :

You can give CompletionStage a pool too. So it helps the other thread bit not this one if we dont make any hazardeous hypothesis. Le 7 mars 2016 23:19, "Reza Rahman" <reza_rahman(a)lycos.com&gt; a écrit : an SPI rather than an end user API like CompletableFuture. For that reason it will never have the level of familiarity that CompletableFuture already does. accomplishes nothing productive. wrote: common end user. If anyone needs custom executor service control in the worst case it's still just a matter of one extra parameter as opposed to introducing an obscure alternative to CompletableFuture. wrote: wrote: been constructed - just take a look at the API. this would run from managed executors of some kind or the other anyway... caller context so it would likely be: should be running from a managed pool that is smart enough to preserve context anyway? If the business developer cares about preserving context in their code, they can use a managed executor themselves on the returned CompletableFuture. the integration with other frameworks - think to security ones in particualr - smooth and doable. to preserve their own context they can simply pass in their own managed executor to both the observer thread and the CompletableFuture. adopt CDI into their applications. Making things harder for them to achieve some limited SPI goal is pretty dangerous. just one in another thread originally? there are at least three different threads associated here in all cases. the fire async thread are all managed executors anyway. At best it's reducing one method parameter. and even if so JavaEE security is not integrated (yet?) at this level. executors. In SE land, the only thing you have is manually writing your own executor to do the same things. These folks will have to pass around their own executors anyway, even to the observer thread. work but since there are cases it would be expected to work and other it shouldn't - from a user point of view auto inheritance can break thread safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed or even just a new scope close to request scoped but inheritable by design. original motivation for adding CompletableFutures? know at least JAX-RS is planning to use CompletableFutures for their client API. rmannibucau(a)gmail.com&gt; wrote: important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. EE ready. it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. wrote: API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. rmannibucau(a)gmail.com&gt; wrote: JDK utilities, event2.fireAsync(...)) impl better CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), CompletableFuture is EE. Using the without the CompletionStage.thenApplyAsync(Function<? super impl. step" is that it's not using async exec (although the "then()" method does not exist). thenCompose, ...) ;). but with these 2 notes: -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Romain Manni-Bucau >>>>>>>>>>>>>> >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>>>>>>>>>> >> <http://rmannibucau.wordpress.com> | Github >>>>>>>>>>>>>> >> <https://github.com/rmannibucau> | LinkedIn >>>>>>>>>>>>>> >> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >>>>>>>>>>>>>> >> <http://www.tomitribe.com> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> _______________________________________________ >>>>>>>>>>>>>> >> cdi-dev mailing list >>>>>>>>>>>>>> >> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> >>>>>>>>>>>>>> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Note that for all code provided on this list, the provider licenses other ideas other 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. 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. 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. 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. 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. 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.

Le 7 mars 2016 23:40, "Reza Rahman" <reza_rahman(a)lycos.com&gt; a écrit : to deal with one anyway - whether by needing to pass it to the observer dispatcher or the CompletableFuture. CompletableFuture gateway API. Hence it is mostly functionally equivalent. What's so surprising about that? CompletableFuture yourself: https://rmannibucau.wordpress.com/2016/02/25/the-promise-of-completablefu.... You should already understand the issue of familiarity for that reason alone. If CompletionStage is so great why didn't you write about it? You are hardly alone. Look at pretty much everyone that speaks or write on the topic. They all start with CompletebleFuture unsurprisingly. Cause it is used as a promise which is irrelevant for cdi topic. another bad API in Java EE for no good reason. > Sent from my iPhone > On Mar 7, 2016, at 5:26 PM, Romain Manni-Bucau <rmannibucau(a)gmail.comwrote: >> You can give CompletionStage a pool too. So it helps the other thread bit not this one if we dont make any hazardeous hypothesis. >>> Le 7 mars 2016 23:19, "Reza Rahman" <reza_rahman(a)lycos.com&gt; a écrit : >> >> > What is still true for CompletionStage? As I've indicated, it's largely an SPI rather than an end user API like CompletableFuture. For that reason it will never have the level of familiarity that CompletableFuture already does. >> >> > Let's kindly not argue in circles or repeat ourselves needlessly. It accomplishes nothing productive. >> >> > On Mar 7, 2016, at 5:07 PM, Romain Manni-Bucau <rmannibucau(a)gmail.comwrote: >> >> >> Side note: this is still true for CompletionStage. >> >>> >> Le 7 mars 2016 22:48, "Reza Rahman" <reza_rahman(a)lycos.com&gt; a écrit : >> >>>> >>> Not sure how alias works, so resending directly. Responses inline. >> >>>> >>> The bottom line is that we should think about the usability of the most common end user. If anyone needs custom executor service control in the worst case it's still just a matter of one extra parameter as opposed to introducing an obscure alternative to CompletableFuture. >> >>>> >>> On Mar 7, 2016, at 4:38 PM, Reza Rahman <reza_rahman(a)lycos.comwrote: >> >>>> >>>> Responses in-line. >> >>>>> >>>> Sent from my iPhone >> >>>>> >>>> On Mar 7, 2016, at 4:24 PM, Romain Manni-Bucau < rmannibucau(a)gmail.com&gt; wrote: >> >>>>> >>>>>> >>>>> 2016-03-07 22:09 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >> >>>>>>> >>>>>> Responses in-line. >> >>>>>>> >>>>>> On Mar 7, 2016, at 3:35 PM, Romain Manni-Bucau < rmannibucau(a)gmail.com&gt; wrote: >> >>>>>>> >>>>>>>> >>>>>>> 2016-03-07 20:53 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >> >>>>>>>>> >>>>>>>> Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API. >> >>>>>>>>> >>>>>>>> >>>>>>> so - just to try to ensure we speak about the same thing: >> >>>>>>>> >>>>>>> asyncEvent.fireAsync(...).thenRunAsync(() -> ..., eePool); ? >> >>>>>>> >>>>>>> >>>>>> Correct. >> >>>>>>> >>>>>>>> >>>>>>> This works but has the drawback to not reuse the observer thread >> >>>>>>> >>>>>>> >>>>>> Why would this matter to the average business code developer? All this would run from managed executors of some kind or the other anyway... >> >>>>>>> >>>>>>> and keep the original issue: the observer doesn't inherit from the caller context so it would likely be: >> >>>>>>>> >>>>>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ..., eePool); >> >>>>>>> >>>>>>> >>>>>> Again, why does it matter really? The observer threads themselves should be running from a managed pool that is smart enough to preserve context anyway? If the business developer cares about preserving context in their code, they can use a managed executor themselves on the returned CompletableFuture. >> >>>>>>> >>>>>> >>>>> Cause it is important to state which thread context is there to keep the integration with other frameworks - think to security ones in particualr - smooth and doable. >> >>>>> >>>>> >>>> For framework developers usability is hardly a concern. If they need to preserve their own context they can simply pass in their own managed executor to both the observer thread and the CompletableFuture. >> >>>>> >>>> In the end, the primary focus should be the masses that we hope will adopt CDI into their applications. Making things harder for them to achieve some limited SPI goal is pretty dangerous. >> >>>>> >>>>>>>> >>>>>>> which looks weird since you trigger 2 tasks where you actually want just one in another thread originally? >> >>>>>>> >>>>>>> >>>>>> I don't follow. Whichever executor service you would use, ultimately there are at least three different threads associated here in all cases. >> >>>>>>> >>>>>>>> >>>>>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...); // in the fire async thread >> >>>>>>> >>>>>>> >>>>>> You mean using the same executor? Why does this matter really? They are all managed executors anyway. At best it's reducing one method parameter. >> >>>>>>> >>>>>> >>>>> Cause very few apps are 100% EE in practise, probably never will be and even if so JavaEE security is not integrated (yet?) at this level. >> >>>>> >>>>> >>>> There is no such thing as context propagation outside of EE managed executors. In SE land, the only thing you have is manually writing your own executor to do the same things. These folks will have to pass around their own executors anyway, even to the observer thread. >> >>>>> >>>>>>> Are >> >>>>>>> This last proposal works not that bad if context propagation would work but since there are cases it would be expected to work and other it shouldn't - from a user point of view auto inheritance can break thread safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed or even just a new scope close to request scoped but inheritable by design. >> >>>>>>>> >>>>>>>>> >>>>>>>> As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures? >> >>>>>>>>> >>>>>>>> Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API. >> >>>>>>>>> >>>>>>>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau < rmannibucau(a)gmail.com&gt; wrote: >> >>>>>>>>> >>>>>>>>>> >>>>>>>>> 2016-03-07 20:35 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >> >>>>>>>>>>> >>>>>>>>>> Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. >> >>>>>>>>>>> >>>>>>>>>> Basically this means CompletableFutures are already pretty Java EE ready. >> >>>>>>>>>>> >>>>>>>>>> If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? >> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. >> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman <reza_rahman(a)lycos.comwrote: >> >>>>>>>>>>> >>>>>>>>>>> I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API. >> >>>>>>>>>>>> >>>>>>>>>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau < rmannibucau(a)gmail.com&gt; wrote: >> >>>>>>>>>>>> >>>>>>>>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba <mkouba(a)redhat.com&gt;: >> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a): >> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Le 7 mars 2016 08:35, "Martin Kouba" <mkouba(a)redhat.com >> >>>>>>>>>>>>>> <mailto:mkouba@redhat.com>> a écrit : >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a): >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Hi guys, >> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >> as a user having a ComlpetionStage makes me loose some JDK utilities, >> >>>>>>>>>>>>>> >> can we move back to CompletionFuture? >> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >> It would allow for instance: >> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >> // doesn't work with CompletionStage >> >>>>>>>>>>>>>> >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)) >> >>>>>>>>>>>>>> >> .then(...) >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> > Well, this should work if the underlying CompletionStage impl >> >>>>>>>>>>>>>> supports toCompletableFuture(), i.e. in Weld 3: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes but it is not natural to convert it IMO = we can do better >> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), >> >>>>>>>>>>>>>> event2.fireAsync(...).toCompletableFuture()) >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> > AFAIK the default async execution facility of CompletableFuture is Java EE. Using the calls without the CompletionStage.thenApplyAsync(Function<? super the impl. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Should use the pool in which the evznt is fired then "then step" is >> >>>>>>>>>>>>>> synchronous is my sample so all is decided at fire time >> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist). >> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;). >> >>>>>>>>>>>>> >>>>>>>>>>>> That said I agree on the state switching the pool is better but with these 2 notes: >> >>>>>>>>>>>>> >>>>>>>>>>>> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml) >> >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >> Romain Manni-Bucau >> >>>>>>>>>>>>>> >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> >>>>>>>>>>>>>> >> <http://rmannibucau.wordpress.com> | Github >> >>>>>>>>>>>>>> >> <https://github.com/rmannibucau> | LinkedIn >> >>>>>>>>>>>>>> >> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >> >>>>>>>>>>>>>> >> <http://www.tomitribe.com>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >> _______________________________________________ >> >>>>>>>>>>>>>> >> cdi-dev mailing list >> >>>>>>>>>>>>>> >> cdi-dev(a)lists.jboss.org <mailto: cdi-dev(a)lists.jboss.org>> >>>>>>>>>>>>>> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >> Note that for all code provided on this list, the provider licenses all other ideas other >> >>>>>>>>>>>>>> intellectual property rights inherent in such information. >> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> > -- >> >>>>>>>>>>>>>> > Martin Kouba >> >>>>>>>>>>>>>> > Software Engineer >> >>>>>>>>>>>>>> > Red Hat, Czech Republic >> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >> >>>>>>>>>>>>> Martin Kouba >> >>>>>>>>>>>>> Software Engineer >> >>>>>>>>>>>>> Red Hat, Czech Republic >> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>>> cdi-dev mailing list >> >>>>>>>>>>>> cdi-dev(a)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. >> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >> >>>>>>>>>> cdi-dev mailing list >> >>>>>>>>>> cdi-dev(a)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. >> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >> >>>>>>>> cdi-dev mailing list >> >>>>>>>> cdi-dev(a)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. >> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >> >>>>>> cdi-dev mailing list >> >>>>>> cdi-dev(a)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. >> >>>>>> >>>>>> >>>> >>> _______________________________________________ >> >>> cdi-dev mailing list >> >>> cdi-dev(a)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. >> >> >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev(a)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. > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)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.

2016-03-08 0:01 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: Only the chaining part is useful, the promise (setResult(), setError() side of promises) is an implementation detail. if you want an impl checking the container state to throw an IllegalStateException if the CDI context is down when the chain is triggered you can today.