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.
