[cdi-dev] What about @AsyncObserves ?

Thu Mar 19 18:32:19 EDT 2015

Hi,

On Thu, Mar 19, 2015 at 8:43 PM, Mark Struberg <struberg at yahoo.de> wrote:

> Imagine you write some business code and your Observer needs a
> @RequestScoped LoggedInUser.
> The event gets fired by some cool library you use.
>
> Now this cool library updates to CDI-2.0 and uses fireAsync from now on.
> But your code still needs the @RequestScoped LoggedInUser on the same
> thread -> booooom.
>

You are right that this would indeed break, and that's of course bad.

This particular situation might be prevented though by having an
@RequestScoped producer for LoggedInUser, that fetches the application
specific representation of the user based on the user/caller principal. If
the request scope is not propagated to async observers, but the security
context is, then the code would keep working and only behind the scenes
will cause the producer method to be called again.

But that's just for this particular situation. Any dependency on other
kinds of request scoped beans would still fail of course.

Kind regards,
Arjan Tijms

>
> LieGrue,
> strub
>
> > Am 19.03.2015 um 18:17 schrieb José Paumard <jose.paumard at gmail.com>:
> >
> > I see the situation as being :
> > - CDI 1.x : I call event.fireEvent(...), there is an observer that is
> called. Currently it is called in the same thread.
> > - CDI 2.0 : I call event.fireEvent(...), there is an observer that is
> called. It will be called in the same thread.
> >
> > So what is the backward compatibility issue here ? From what I
> understand it just works the same.
> >
> > José
> >
> >
> > 2015-03-19 17:19 GMT+01:00 Antoine Sabot-Durand <
> antoine at sabot-durand.net>:
> > The killer argument is that nobody succeed to provide a way to prevent
> opt-in and keep backward compaibility. The problem comes from the fact that
> producer and consumer can be in different jar compiled with different
> version of CDI  and running on CDI 2.0 preventing using opt-out.
> > If you have the solution without opt-in I’m all ears.
> >
> >
> >> Le 19 mars 2015 à 16:52, José Paumard <jose.paumard at gmail.com> a écrit
> :
> >>
> >> > So it seems impossible to avoid opt-in on the observer side
> >> What is the "killer" argument for that ?
> >>
> >> José
> >>
> >> 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 ?
> >>
> >>>
> >>> Do we really want this feature at this price?
> >>
> >> #1 requested feature by users.
> >>
> >>> 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...
> >>
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >>>
> >>> 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.
> >>>
> >>
> >>
> >> _______________________________________________
> >> 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.
> >>
> >>
> >>
> >> --
> >> Java le soir Cours Java en ligne
> >> Twitter Paris JUG Devoxx France
> >> M : +33 6 76 82 91 47
> >
> >
> >
> >
> > --
> > Java le soir Cours Java en ligne
> > Twitter Paris JUG Devoxx France
> > M : +33 6 76 82 91 47
> > _______________________________________________
> > 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.
>
>
> _______________________________________________
> 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/fa89ec2d/attachment.html 