[cdi-dev] What about @AsyncObserves ?

[Romain Manni-Bucau]

2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:

>
> Le 19 mars 2015 à 15:51, Romain Manni-Bucau <rmannibucau at 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/ContextService.html

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.


> 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 at 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 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.
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/814a7e9a/attachment.html