@Romain By "request scoped event" you mean that all @Observes methods for that particular event is in @RequestScoped beans or is it possible to fire events so they are only visible to the current request?
On Sun, Sep 21, 2014 at 12:06 AM, Romain Manni-Bucau <[email protected]> wrote: > oh sorry, read async (the habit). In this case a request scoped even > should work > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > 2014-09-20 23:51 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: > > @Romain > > > > Its an synchronous task, not async. How can I then make sure no events > are > > shared between requests? (or did I misunderstand your answer perhaps?) > > > > Regards > > LF > > > > On Sat, Sep 20, 2014 at 11:48 PM, Romain Manni-Bucau < > [email protected]> > > wrote: > >> > >> if that's async then you have no guarantee out of the box that it will > >> work, I wouldn't bet on it without being bound to a particular > >> container > >> > >> > >> Romain Manni-Bucau > >> Twitter: @rmannibucau > >> Blog: http://rmannibucau.wordpress.com/ > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau > >> Github: https://github.com/rmannibucau > >> > >> > >> 2014-09-20 23:35 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: > >> > Hi Romain and Mark > >> > > >> > I was exploring the thoughts of using CDI Events to perform something > >> > like > >> > this. > >> > > >> > 1. In a request start a syncrhonous task > >> > 2. The task would at some points during the process (not always, > depends > >> > on > >> > some business decisions) send events that the starter of the task > could > >> > observe and possible change the outcome of the task. > >> > 3. When the task is finished the request that started it returns an > >> > answer > >> > to the client > >> > > >> > Another way would be to create normal listeners (normal e.g. as used > in > >> > Swing, addActionListener...) > >> > > >> > Is the CDI Event way something to consider (seems more elegant)? I > would > >> > not > >> > want observers of different requests (threads) see each others events. > >> > > >> > Regards > >> > LF > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > On Sat, Sep 20, 2014 at 7:46 AM, Mark Struberg <[email protected]> > >> > wrote: > >> >> > >> >> s/mathing/matching/g > >> >> > >> >> > >> >> > >> >> > >> >> > On Saturday, 20 September 2014, 7:46, Mark Struberg > >> >> > <[email protected]> > >> >> > wrote: > >> >> > > Yes all beans which are in active contests and have a mathing > >> >> > > observer > >> >> > > method. > >> >> > > >> >> > > >> >> > How does it work: > >> >> > > >> >> > 1.) We collect all ObserverMethods which match the type and > generics > >> >> > info > >> >> > > >> >> > 2.) From those ObserverMethods we filter out all which do not fit > the > >> >> > qualifier > >> >> > > >> >> > 3.) Then we iterate over all the ObserverMethods and do the > following > >> >> > > >> >> > 3.1) if the Scope of the bean containing the ObserverMethod is not > >> >> > active -> > >> >> > skip it. (this can happen if you e.g. have a SessionScoped bean in > an > >> >> > @Scheduled > >> >> > management thread) > >> >> > > >> >> > 3.2) if there is already a Contextual Instance in the Context of > the > >> >> > Scope we > >> >> > call the observer method on that instance. > >> >> > > >> >> > 3.3.) if there is NO active Contextual Instance of the bean > >> >> > containing > >> >> > the > >> >> > observer method yet and the @Observes has > >> >> > javax.enterprise.event.Reception.ALWAYS (which is the default) then > >> >> > we > >> >> > will > >> >> > first create the Contextual Instance and then call the method. > >> >> > > >> >> > 3.4) ATTENTION: There is a special rule for @Dependent scoped > beans. > >> >> > For > >> >> > those > >> >> > we must create a NEW instance every time and after the observer > >> >> > method > >> >> > returns > >> >> > we will throw the instance away immediately. > >> >> > If you have a @Dependent bean injected into some other normalscoped > >> >> > beans then > >> >> > CDI will NOT invoke the observer methods on those instances! Which > >> >> > effectively > >> >> > renders observing events in @Dependent beans pretty much useless. > >> >> > Just > >> >> > as a side > >> >> > note... > >> >> > > >> >> > > >> >> > LieGrue, > >> >> > strub > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >> On Friday, 19 September 2014, 23:09, Romain Manni-Bucau > >> >> > <[email protected]> wrote: > >> >> >> > Hi > >> >> >> > >> >> >> basically the scope will be the one of the observing bean. There > is > >> >> >> no > >> >> >> filter by scope in notification triggering. > >> >> >> > >> >> >> > >> >> >> Romain Manni-Bucau > >> >> >> Twitter: @rmannibucau > >> >> >> Blog: http://rmannibucau.wordpress.com/ > >> >> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau > >> >> >> Github: https://github.com/rmannibucau > >> >> >> > >> >> >> > >> >> >> > >> >> >> 2014-09-19 22:00 GMT+02:00 Lars-Fredrik Smedberg > >> >> > <[email protected]>: > >> >> >>> Hi! > >> >> >>> > >> >> >>> When firing an CDI-Event, beans in what scope will be able to > >> >> >>> @Observe > >> >> > it? > >> >> >>> Is it @ApplicationScoped, @SessionScoped belonging to the same > >> >> >>> session > >> >> > as > >> >> >>> the one it was fired from and @RequestScoped belonging to the > >> >> >>> same > >> >> > thread > >> >> >> as > >> >> >>> the one it was fired from? (We do not use any JSF and > >> >> > @ConversationScoped > >> >> >>> beans). > >> >> >>> > >> >> >>> Could someone clarify this and if possible point to some specs > >> >> >>> and > >> >> > chapters > >> >> >>> for me to read about it in more detail? I did look in JSR299 > but > >> >> >>> I > >> >> > might > >> >> >>> have overlooked it. > >> >> >>> > >> >> >>> Thanks > >> >> >>> Lars-Fredrik > >> >> >>> > >> >> >>> -- > >> >> >>> Med vänlig hälsning / Best regards > >> >> >>> > >> >> >>> Lars-Fredrik Smedberg > >> >> >>> > >> >> >>> STATEMENT OF CONFIDENTIALITY: > >> >> >>> The information contained in this electronic message and any > >> >> >>> attachments to this message are intended for the exclusive use > of > >> >> >>> the > >> >> >>> address(es) and may contain confidential or privileged > >> >> >>> information. > >> >> >>> If > >> >> >>> you are not the intended recipient, please notify Lars-Fredrik > >> >> > Smedberg > >> >> >>> immediately at [email protected], and destroy all copies of > this > >> >> >>> message and any attachments. > >> >> >> > >> >> > > >> > > >> > > >> > > >> > > >> > -- > >> > Med vänlig hälsning / Best regards > >> > > >> > Lars-Fredrik Smedberg > >> > > >> > STATEMENT OF CONFIDENTIALITY: > >> > The information contained in this electronic message and any > >> > attachments to this message are intended for the exclusive use of the > >> > address(es) and may contain confidential or privileged information. If > >> > you are not the intended recipient, please notify Lars-Fredrik > Smedberg > >> > immediately at [email protected], and destroy all copies of this > >> > message and any attachments. > > > > > > > > > > -- > > Med vänlig hälsning / Best regards > > > > Lars-Fredrik Smedberg > > > > STATEMENT OF CONFIDENTIALITY: > > The information contained in this electronic message and any > > attachments to this message are intended for the exclusive use of the > > address(es) and may contain confidential or privileged information. If > > you are not the intended recipient, please notify Lars-Fredrik Smedberg > > immediately at [email protected], and destroy all copies of this > > message and any attachments. > -- Med vänlig hälsning / Best regards Lars-Fredrik Smedberg STATEMENT OF CONFIDENTIALITY: The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the address(es) and may contain confidential or privileged information. If you are not the intended recipient, please notify Lars-Fredrik Smedberg immediately at [email protected], and destroy all copies of this message and any attachments.
