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&gt; 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

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&gt; 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&gt; 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&gt; 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

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&gt; 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&gt; 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&gt; 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&gt; 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 >

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&gt; 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&gt; 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&gt; 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&gt; 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 >

Forgot one point about metadata unavailability. When I @Observes an event without a qualifier, I will catch all the events of this type with whatever qualifier(s) they have. and I have no mean to get the set of qualifiers on the event I caught. Could be a real problem for some use case... A mission for CDI 2.0 I guess... Antoine Le 18 mars 2014 à 15:35, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; a écrit : > John, > > Sorry but it's wrong. According to 10.2 in 1.1 spec [1] if you launch an event with @Added and @Book(Fiction) all the observers with a subset of these qualifiers (including empty set) will be called. Here that will be > > afterFictionBookAdded > afterBookAdded > onBookEvent > > As I told when I started this thread (please read the IRC transcript if you want to catch up the conversation), this is how it is supposed to work in the spec and hopefully this is how it works in OWB and Weld 1 and 2 according to the tests I created [2] before starting this thread. > > That brings 2 questions : > > - The role of @Any regarding Event<> and @Observes qualification (it seems totally useless) and the fact that event examples in the spec use @Any (that bring a lot of confusion especially regarding next point) > - More generally the fact that event qualification work totally differently than standard qualification and that we don't mention it anywhere. Ok you can guess it by reading carefully, but most CDI user I spoke with regarding this point made the mistake. > > Antoine > > > [1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#observer_resolution > [2] https://github.com/antoinesd/EventsTest > > > Le 17 mars 2014 à 12:56, John D. Ament <john.d.ament(a)gmail.com&gt; a écrit : > >> 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&gt; 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&gt; 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&gt; 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&gt; 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 >>> >

Thanks John, I missed this eventMetadata CDI 1.1 addition :-). I'm not sure to understand what you mean by starting your mail by << No, I side with your view point >>. The way events are working seem to have been the result of long thought [1]. Personnaly I don't want to change the way it's working now, I only want to make it clear for users (and for us apparently). As it was decided in yesterday meeting, we should create a ticket on the subject to classify the event chapter. Do you agree ? Antoine [1] https://issues.jboss.org/browse/CDI-7 Le 18 mars 2014 à 16:11, John D. Ament <john.d.ament(a)gmail.com&gt; a écrit : > Antoine, > > No, I definitely side with your view point. The issue around event > qualification is also confusing for developers I've brought in to CDI. > > BTW, I think you added EventMetadata in 1.1. See [1] > > [1]: http://docs.jboss.org/cdi/api/1.1/javax/enterprise/inject/spi/EventMetada... > > On Tue, Mar 18, 2014 at 10:47 AM, Antoine Sabot-Durand > <antoine(a)sabot-durand.net&gt; wrote: >> Forgot one point about metadata unavailability. >> >> When I @Observes an event without a qualifier, I will catch all the events of this type with whatever qualifier(s) they have. and I have no mean to get the set of qualifiers on the event I caught. Could be a real problem for some use case... >> >> A mission for CDI 2.0 I guess... >> >> Antoine >> >> >> Le 18 mars 2014 à 15:35, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; a écrit : >> >>> John, >>> >>> Sorry but it's wrong. According to 10.2 in 1.1 spec [1] if you launch an event with @Added and @Book(Fiction) all the observers with a subset of these qualifiers (including empty set) will be called. Here that will be >>> >>> afterFictionBookAdded >>> afterBookAdded >>> onBookEvent >>> >>> As I told when I started this thread (please read the IRC transcript if you want to catch up the conversation), this is how it is supposed to work in the spec and hopefully this is how it works in OWB and Weld 1 and 2 according to the tests I created [2] before starting this thread. >>> >>> That brings 2 questions : >>> >>> - The role of @Any regarding Event<> and @Observes qualification (it seems totally useless) and the fact that event examples in the spec use @Any (that bring a lot of confusion especially regarding next point) >>> - More generally the fact that event qualification work totally differently than standard qualification and that we don't mention it anywhere. Ok you can guess it by reading carefully, but most CDI user I spoke with regarding this point made the mistake. >>> >>> Antoine >>> >>> >>> [1] http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#observer_resolution >>> [2] https://github.com/antoinesd/EventsTest >>> >>> >>> Le 17 mars 2014 à 12:56, John D. Ament <john.d.ament(a)gmail.com&gt; a écrit : >>> >>>> 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&gt; 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&gt; 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&gt; 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&gt; 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 >>>>> >>> >>