[cdi-dev] Scoped CDI Events?

Pete Muir pmuir at redhat.com
Wed Aug 29 09:25:06 EDT 2012 

On 29 Aug 2012, at 13:52, Martin Kouba wrote:

> Hi Adam,
> 
> comments inline...
> 
> Dne 29.8.2012 14:43, Adam Bien napsal(a):
>> Hi *,
>> 
>> it would mean:
>> 
>> If you are sending an event from a @RequestScoped bean all @SessionScoped observes (= all sessions) would receive that? Or more precisely ALL observes are intended to receive an event regardless of their scope?
> 
> Yes.

Actually, no. Working through the spec:

10.5 says

"When an event is fired by the application, the container must:

	• determine the observer methods for that event according to the rules of observer resolution defined by Section 10.2, “Observer resolution”, then,

	• for each observer method, either invoke the observer method immediately, or register the observer method for later in- vocationduringthetransactioncompletionphase,usingaJTASynchronization.

The container calls observer methods as defined in Section 5.5.6, “Invocation of observer methods”."

and 5.5.6 says

"	• Obtain a contextual instance of the bean which declares the observer method according to Section 6.5.2, “Contextual instance of a bean”. If this observer method is a conditional observer method, obtain the contextual in- stance that already exists, only if the scope of the bean that declares the observer method is currently active, without creating a new contextual instance.

	• Invoke the observer method on the resulting instance, if any, as a business method invocation, as defined in Sec- tion 7.2, “Container invocations and interception”."

and 6.5.2 says

"From time to time, the container must obtain a contextual instance of a bean. The container must:

	• obtain the active context object for the bean scope, then

	• obtain an instance of the bean by calling Context.get(), passing the Bean instance representing the bean and an in- stance of CreationalContext."

Finally, we need to look at 6.3, which defines how normal scopes work. Specifically, we can see that "The get() operation of the context object for an active normal scope returns the current instance of the given contextual type."and that "The context associated with the current thread is called the current context for the scope. The mapped instance of a contex- tual type associated with a current context is called the current instance of the contextual type."

If we put that together, we can see that observer methods, on any bean of any scope are called *only* for the session associated with the current request.

Events *do not* provide a way to widen a context. It's definitely not recommended to bridge sessions this way. Instead, you should inject an application scoped bean, or observe an event on application scoped bean.

> 
>> 
>> If so: in the spec an injection of @Dependent Event is mentioned:
>> 
>> "10.3.2. The built-in Event
>> The container must provide a built-in bean with:
>> 
>> 	• Event<X> in its set of bean types, for every Java type X that does not contain a type variable,
>> 
>> 	• every event qualifier type in its set of qualifier types,
>> 
>>>> 	• scope @Dependent, <<
>> 
>> 	• no bean EL name, and
>> 
>> 	• an implementation provided automatically by the container.
>> 
>> ..."
> 
> This is the built-in bean used to fire events (an alternative to BeanManager#fireEvent()).
> 
>> 
>> It implies, that only observes belonging to the same scope would be notified. Otherwise this information is irrelevant,
> 
> No, I don't think so. It only says that if you use built-in bean Event to fire events, it will depend on the bean where you inject it.

No it doesn't. It's just describing how the built in Event bean works, not how observers are notified (which I outlined above for your bedtime reading :-)

> 
>> 
>> 
>> thanks!,
>> 
>> adam
>> 
>> On 29.08.2012, at 13:54, Pete Muir <pmuir at redhat.com> wrote:
>> 
>>> Resolution and scoping are orthogonal concepts in CDI. I'm not aware of a use case that is well addressed by considering scope as part of resolution.
>>> 
>>> On 29 Aug 2012, at 11:43, Martin Kouba wrote:
>>> 
>>>> No. It will be delivered to any matching observer method - belongs to an enabled bean, the event object is assignable to the observed event type and the observer method has all the event qualifiers (CDI 1.0). In CDI 1.1 qualifier matching rules will likely change: "The observer method has no event qualifiers or has a subset of the event qualifiers".
>>>> 
>>>> (see 10.2. Observer resolution)
>>>> 
>>>> Martin
>>>> 
>>>> Dne 29.8.2012 12:32, Adam Bien napsal(a):
>>>>> HI Martin,
>>>>> 
>>>>> sure. But will the unmanaged payload be delivered only to observers belonging to the same scope as the sender?
>>>>> 
>>>>> I didn't found any mention in the spec about that...
>>>>> 
>>>>> thanks,
>>>>> 
>>>>> adam
>>>>> On 29.08.2012, at 12:14, Martin Kouba <mkouba at redhat.com> wrote:
>>>>> 
>>>>>> Hi Adam, Arne,
>>>>>> 
>>>>>> The built-in Event bean is not stateless, it's @Dependent. The event payload - the event object - is really not managed and thus not scoped (and should not be IMHO). I also think the event object should be immutable since the order in which observer methods are called is not defined...
>>>>>> 
>>>>>> Martin
>>>>>> 
>>>>>> 
>>>>>> Dne 29.8.2012 12:06, Arne Limburg napsal(a):
>>>>>>> Hi Adam,
>>>>>>> 
>>>>>>> 
>>>>>>> Are you talking about the injected Event object or about the payload?
>>>>>>> The Event object is stateless so the scope does not matter.
>>>>>>> And the payload is not managed at all.
>>>>>>> So, I'm afraid, I can't see your issue here?
>>>>>>> Could you provide a use case for a scoped event?
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Arne
>>>>>>> 
>>>>>>> Am 29.08.12 11:49 schrieb "Adam Bien" unter <abien at adam-bien.com>:
>>>>>>> 
>>>>>>>> Hi *,
>>>>>>>> 
>>>>>>>> I didn't found in the CDI 1.0 spec a mention of the scope of CDI events.
>>>>>>>> There is also no mention of scopes in the Observer Resolution section.
>>>>>>>> 
>>>>>>>> Are CDI events scoped?
>>>>>>>> 
>>>>>>>> Does observer resolution depend on the scope of the injected Event
>>>>>>>> instance?
>>>>>>>> 
>>>>>>>> Should we refine/clarify that in the CDI 1.1 spec?
>>>>>>>> 
>>>>>>>> I didn't found an explicit mail in the archives either,
>>>>>>>> 
>>>>>>>> thanks and sorry in case the issue is already resolved,
>>>>>>>> 
>>>>>>>> adam
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Martin Kouba
>>>>>> JBoss Quality Assurance Engineer
>>>>>> CDI TCK lead
>>>>>> E-mail: mkouba at redhat.com
>>>>>> Web: www.cz.redhat.com
>>>>>> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>> 
>>>>> workshops.adam-bien.com
>>>>> blog.adam-bien.com
>>>>> about.adam-bien.com
>>>>> 
>>>>> Author of:
>>>>> "Real World Java EE Night Hacks", "Real World Java EE Patterns--Rethinking Best Practices"
>>>>> 
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>> 
>>  workshops.adam-bien.com
>>  blog.adam-bien.com
>>  about.adam-bien.com
>> 
>>  Author of:
>>  "Real World Java EE Night Hacks", "Real World Java EE Patterns--Rethinking Best Practices"
>> 
>> 
>> 
>> 
>> 
>>

More information about the cdi-dev mailing list