Oh, yes Pete is right. I misread Adam's question. Sorry for confusion.
Pete: Maybe this should be clarified somehow somewhere so that is't a little bit more
clear... Something like:
"For normal scoped beans the event is delivered to observer methods of the current
instances of the contextual type."
Martin
Dne 29.8.2012 15:25, Pete Muir napsal(a):
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(a)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(a)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(a)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(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Martin Kouba
>>>>>> JBoss Quality Assurance Engineer
>>>>>> CDI TCK lead
>>>>>> E-mail: mkouba(a)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(a)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(a)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"
>>
>>
>>
>>
>>
>>