public class MyRequestController {
void stopAll() {}
}
class Observer {
@Inject MyRequestController controller;
void observes(@Observes MyEvent event ) { controller.stopAll(); }
}
public class MyServlet extends HttpServlet {
@Inject MyRequestController controller;
void service(req, resp) {
controller.start(....);
}
}
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-09-21 0:36 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>:
> @Romain
>
> Could you please give me a short example (psuedo code)... not quite sure if
> I get it...
>
> Thanks
> LF
>
> On Sun, Sep 21, 2014 at 12:26 AM, Romain Manni-Bucau <[email protected]>
> wrote:
>>
>> what I usually do is to either get injected in the observer or pass as
>> event parameter something related to the request. Can be your 'request
>> processor'
>>
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>> 2014-09-21 0:20 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>:
>> > @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.
>
>
>
>
> --
> 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.
