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(a)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(a)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