On 29 Aug 2012, at 11:30, Jens Schumann wrote:
Hi Martin,
If possible I would like to avoid immutable event objects, even though the
order of observer methods is currently undefined. I have a couple of use
cases where my event object will be modified by event observers. Two
examples:
- Execute secondary business logic after an entity was created/updated and
add details to the entity. Here we might have ordering issues. However we
did not encounter issues so far. We fire @Created or @Updated Entity
events, where my payload is the entity itself. Example: Send welcome
e-mail after a new customer was created. The primary business logic will
create the customer and fire an @Created Customer event. A
WelcomeMailObserver observes @Created Customer events, sends the e-mail
and links it to the new customer.
- Collect application wide information, e.g. statistics or health status
information. My observers simply add local statistics or local health
status details to the event object itself.
This is very similar to making things threadsafe - immutability is a simple way to
guarantee thread safety, but you can make mutable objects threadsafe if you reason about
how they will be used. Same with event payloads - it's simple to make them immutable,
but you can mutate them if you can reason correctly about it.
I don't think there is any spec work here, perhaps just a FAQ.
Jens
Am 29.08.12 12:14 schrieb "Martin Kouba" unter <mkouba(a)redhat.com>:
> 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
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev