On 19 Mar 2015, at 15:54, Romain Manni-Bucau
<rmannibucau(a)gmail.com> wrote:
2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net
<mailto:antoine@sabot-durand.net>>:
> Le 19 mars 2015 à 15:51, Romain Manni-Bucau <rmannibucau(a)gmail.com
<mailto:rmannibucau@gmail.com>> a écrit :
>
> sounds like a quick and dirty solution to me. @Async will arrive
Yes like in “Async is coming” ;)
> - maybe too early today - but adding @ObservesAsync just cause we dont have yet
@Async will make this API obselete pretty quickly isn't it (already cause of EJB
actually).
and if we add an @Async in our spec you think it’s better ?
no we agree
>
> Do we really want this feature at this price?
#1 requested feature by users.
not a reason to mess up the spec IMO. One of the best feature of EE is its stability,
here I think we break this basic rule knowing it which doesn't sound professional from
my window.
This feature is important but already doable today - I guess all vendors provide a
solution so business wise you are not blocked and you can even stay portable with very few
code (even no code in EE).
Other point is defining a more appropriated API is surely needed interacting with the
@async/threading spec. EE concurrency spec has something which could help in context
propagation if spec is updated:
http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextSe...
<
http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextSe...
can be a way to get context propagation but manually this way it is a "use it at
your own risk" solution which is the best can do.
I agree, we shouldn’t deliver this as currently proposed. What about adding SPI hooks to
the core, so that e.g. DeltaSpike could implement something over the top that allows the
nice programming model. We can then adopt in to the spec in 2.1?
> If yes AsyncObserves sounds an acceptable compromise but still will mess up the API
IMO.
The question is “Is it more or less messy than @Async @Observes?" I don’t know… It
has pros and cons as I listed...
agree, both are intermediary states probably which is not satisfying.
>
>
> 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/>
> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net
<mailto:antoine@sabot-durand.net>>:
> Hi guys,
>
>
> So it seems impossible to avoid opt-in on the observer side for the sake of awkward
compatibility.
> Adding a member to @Observes could also be a source of issues when old CDI lib will
be used with CDI 2.0 runtime. Some of us (including me) don’t want to add an @Async
annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an
@AsyncObserves or @ObservesAsync ?
>
> So it would be
>
> public void myObserver(@AsyncObserves payload) {}
>
> instead of
>
> @Async
> public void myObserver(@Observes payload) {}
>
>
> Pros :
> - it’s a cleaner way to manage the opt-in than to put 2 annotations or add a member
to an existing one
> - it could have new members related to async behavior (context propagation,
concurrent scenario, etc…)
> - As it won’t be in legacy code no risk to see old observers called asynchronously
>
> Cons :
> - Still not clear for users when fire() is called to see @AsyncObserves launched
synchronously
> - Yet another annotation added
>
> wdyt ?
>
> Antoine
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
<
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
<
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.