Hmmm maybe it's a language semantics issue.
I put together a sample project in how I know it works today in Weld
1.x, 2.x and OWB.
https://github.com/johnament/cdi-events
You can run it using -Pweld-2, -Pweld-1 or -Powb
you'll see the first test pass, that correct hits all of the observer
methods from a single fired event.
The second one, which is my understanding of Ken's book's description,
assumes that only the best match and any are hit. Considering that
both Weld and OWB hit all 5 observers, I'm assuming that this is the
intended result.
On Tue, Mar 18, 2014 at 7:11 AM, Pete Muir <pmuir(a)redhat.com> wrote:
Ken's book is correct in this I think.
On 17 Mar 2014, at 11:56, John D. Ament <john.d.ament(a)gmail.com> wrote:
> Correct, I don't believe best match is in any of the CDI spec.
>
> However, this comes straight from Ken's book:
>
> Say we have observer methods such as the following:
>
> public void afterFictionBookAdded(@Observes @Book(FICTION)
> @Added Book book) { ... }
>
> public void afterBookAdded(@Observes @Added Book book) { ... }
>
> public void onBookEvent(@Observes Book book) { ... }
>
> In such cases, only afterFictionBookAdded() will be called as it
> matches the fired event with @Added and @Book(FICTION).
>
> Now say we had an observer method such as the following:
>
> public void afterAdding(@Observes @Any Book book) { ... }
>
> The preceding observer method would also be notified, as @Any informs
> Weld that we want to be notified of all Book events, irrespective of
> what event qualifiers may be set.
>
> On Mon, Mar 17, 2014 at 7:25 AM, Pete Muir <pmuir(a)redhat.com> wrote:
>> There are no "best match" semantics in CDI I know of...
>>
>> On 16 Mar 2014, at 23:56, John D. Ament <john.d.ament(a)gmail.com> wrote:
>>
>>> Funny that this comes up now. I actually hacked into my coworker's
>>> code using an observer on any object.
>>>
>>> I always assumed the use of @Any in the examples came from a different
>>> version of the event observer pattern where it was a best match, not
>>> an any match.
>>>
>>> On Sun, Mar 16, 2014 at 1:51 PM, Pete Muir <pmuir(a)redhat.com> wrote:
>>>> Yeah, agreed, this is something I've puzzled over before.
>>>>
>>>> On 6 Mar 2014, at 11:51, Antoine Sabot-Durand
<antoine(a)sabot-durand.net> wrote:
>>>>
>>>>> Hi all
>>>>>
>>>>>
>>>>> Yesterday when reviewing Martin Pull Request [1] regarding CDI 422
[2], we started a discussion about Observer Resolution about a possible issue in the spec.
I will not repeat what was said on the IRC, if you're interested you can check the
transcript [3] from 09:43.
>>>>>
>>>>> To check if this was an issue or not I did some test this morning
with different implementations. You can grab the tests on Github [4]
>>>>>
>>>>> Good news : OWB and Weld (1.x and 2.x) have the same behavior : the
one describe in the current spec, so there are no issue on this point.
>>>>> The only strange thing for me is that @Any seems totally useless
regarding events firing
>>>>>
>>>>> If you write :
>>>>> @Inject Event<Payload> payLoadEvent;
>>>>> or
>>>>> @Inject @Any Event<Payload> payLoadEvent;
>>>>>
>>>>> You'll always be allowed call payLoadEvent.select(new
QualifierLiteral()) in both case...
>>>>>
>>>>> Perhaps this point can be discussed to see if we remove @Any from the
examples in the spec or if we enforce its usage in the specification...
>>>>>
>>>>> Antoine
>>>>>
>>>>> [1]
https://github.com/cdi-spec/cdi/pull/207
>>>>> [2]
https://issues.jboss.org/browse/CDI-422
>>>>> [3]
http://transcripts.jboss.org/channel/irc.freenode.org/%23jsr346/2014/%23j...
>>>>> [4]
https://github.com/antoinesd/EventsTest
>>>>> _______________________________________________
>>>>> 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
>>