[cdi-dev] On @Observes for async events

Wed Mar 18 04:55:13 EDT 2015

> 
> Le 18 mars 2015 à 09:42, Romain Manni-Bucau <rmannibucau at gmail.com> a écrit :
> 
> Hi guys,
> 
> think Mark is right and a new API (as fireAsync) would be better for users for:
> - understanding
> - compatibility (think to custom extensions using this flag)

My point here is to avoid making CDI the EJB next by introducing @Async or @Asynchronous annotation in the spec. This kind of annotation should be shared by other specs and would have a better fit in concurrency utilities or commons annotations spec.

> that said if we have @Async methods I think async observers are really useless, isn't it?

@Async is rather useless IMO when you see how easy it is do async operation with Java 8. On the other hand Async observers are a at a higher level since they are called thru the Container and that the fire point must know what’s going on at the other side.

> 
> 
> 
> 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-18 9:30 GMT+01:00 Arne Limburg <arne.limburg at openknowledge.de <mailto:arne.limburg at openknowledge.de>>:
> Hi Antoine,
> 
> The third bullet point in 10.5.1 of the CDI 1.1 spec states that the
> observer method must be called in the same transaction context as the
> event.fire(...) if it is no transactional observer (that is
> TransactionPhase.IN_PROGRESS).
> If the default behavior would be async, we would have to move the
> transaction context to another thread. To my best knowledge this would be
> the only situation in EE where this is the case.
> 
> Cheers,
> Arne
> 
> Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter
> <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>>:
> 
> >Hi Arne,
> >
> >Sorry can you explain why? This value allows observer to be called inside
> >or outside a transaction. What will be the compatibility issue?
> >
> >Antoine
> >
> >
> >> Le 18 mars 2015 à 09:05, Arne Limburg <arne.limburg at openknowledge.de <mailto:arne.limburg at openknowledge.de>> a
> >>écrit :
> >>
> >> Hi to all,
> >>
> >> I think the biggest issue with backward compatibility is, that the
> >>current
> >> @Observes annotation by default has TransactionPhase.IN_PROGRESS.
> >> I think we can¹t deal with this, if the default for observers would be
> >> async. So I think there is no way to specify async as default without
> >> loosing backward compatibility.
> >> Any other thoughts?
> >>
> >> Cheers,
> >> Arne
> >>
> >>
> >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter
> >> <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>>:
> >>
> >>> Hi all,
> >>>
> >>> Yesterday we had another meeting to try to find a better solution than
> >>> explicitly activating async event on observer, without no success. I
> >>> understand that we should go on on this feature so what I suggest is to
> >>> have a meeting (an hangout) with people that want to try to find a
> >>>better
> >>> solution. If we find something we¹ll do a last proposal, and in all
> >>>case
> >>> we¹ll adopt the woking solution next week for this point. People
> >>> interested with this please manifest yourself.
> >>>
> >>> If we have to go with opt-in (have to explicitly declare an observer
> >>> supporting async event) we also have to validate the decision to use a
> >>> member in @Observes (as it was decided before) or go back on that as
> >>> mMark keep asking by introducing a new annotation to add on the
> >>>observer
> >>> (@Async or something similar). As I said when we discussed this point,
> >>>I
> >>> prefer the member in @Observes but we may have overlooked issues linked
> >>> to backward compatibility.
> >>> A third solution might be to introduce an @ObserveAsync to declare an
> >>> asynchronous capable observerŠ
> >>>
> >>> I¹m waiting for active feedback from you to find the best solution
> >>>taking
> >>> ALL aspects (not only the technicals one) into account.
> >>>
> >>> Thanks,
> >>>
> >>> Antoine
> >>
> >
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org <mailto:cdi-dev at 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.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/3822ae8d/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/3822ae8d/attachment.bin 