[cdi-dev] On @Observes for async events

Wed Mar 18 05:53:20 EDT 2015

2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:

>
> Le 18 mars 2015 à 09:58, Romain Manni-Bucau <rmannibucau at gmail.com> a
> écrit :
>
>
> 2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:
>
>>
>> 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.
>>
>>
> +1
>
>
>> 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.
>>
>>
> don't get it, observer can use j8 then to do its stuff asynchronously so
> maybe the feature if finally useless assuming you run on j8.
>
>
> And how do you make your fire point know that one of its observer will be
> asynchronous ? How do you manage event ordering (as we plan to support it
> for async event as well). I think we shouldn’t see the event bus as a
> standard method call but something more featured (think about parameter
> injection in observer methods or transactional behavior)
>
>
then this is not asynchronism and just an observer queue which is something
different IMO


>
> That said saying a method is async is still more elegant than firing it in
> a pool you don't control.
>
>
> fireAsync will have a signature allowing you to pass your own Executor to
> give you better control on thread pool
>
>
a default one should be bound to the bm - main case IMO. having an app
executor is not a very nice solution in term of API.

>
>
>>
>>
>>
>> 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/4c7348a4/attachment-0001.html