[cdi-dev] On @Observes for async events

[Romain Manni-Bucau]

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)

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



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>:

> 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>:
>
> >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> 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>:
> >>
> >>> 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
> 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/20150318/a0d7bb55/attachment-0001.html