[cdi-dev] Problem with resolution of CDI-271 - Does not address original intent of issue (CDI-71)

[Jozef Hartinger]

I support this proposal. I would add getType() because the final event 
type used for observer method resolution may be difficult to infer. (see 
10.3.1)

On 03/06/2013 06:36 PM, Lincoln Baxter wrote:
> Hey Folks,
>
> I've just (a little late,) come to review the solution that was implemented for CDI-271 [0] about 10 days ago. This was provided as an alternate solution to the lack of payload qualifier information (resulting in highly-coupled observer methods) originally requested in issues CDI-36 and CDI-71 [1] [2]. With this implementation, CDI-36 and CDI-71 are no longer resolved and should be re-opened.
>
> However, it seems that the original intent of these issues, which was to make event payload qualifier information available to observer methods, has been missed with this latest implementation in CDI-271. (I think probably because the issue titles did not actually describe the real intent, other than CDI-71, so it was easy to forget).
>
> The result is that only "origin information" (where the event was fired from, and qualifiers of that source) are retrievable, and payload information has again been lost. This makes it impossible to implement certain features reliably (as outlined in my comment on CDI-271).
>
> While I do think that "origin information" is important to have, I think that it would be a big gap to once again omit the "payload information" that people have been asking for. I have proposed a solution to this in the comments of CDI-271, but would be happy to re-open a new issue if needed to resolve this.
>
> I propose the following additional (psuedo-code) API to provide the necessary "payload information" that the original issues required. This would not require any changes to the implementation of CDI-271, as they are somewhat orthogonal concerns actually (so we got another feature for "free' with CDI-271), but we still need something like this:
>
> My recommendation would be to add another Interface like, "EventMetadata" that can be injected in place of InjectionPoint in your examples above:
>
>     public void handleEvent(@Observes @Any Object event, EventMetadata ip)
>     {
>     }
>
> Where EventMetadata allows for operation such as:
>
>     /**
>      * Provides meta-information about an observed event payload. Can be retrieved as a parameter of an @Observes method.
>      */
>     public interface EventMetadata {
>        /**
>         * Returns the set of qualifiers with which the corresponding event payload was fired.
>         */
>        public Set<Annotation> getQualifiers();
>
>        /**
>         * Returns the Event<?> InjectionPoint from which this payload was fired, or null if it was fired from BeanManager.fireEvent(...);
>         */
>        public Set<Annotation> getInjectionPoint(); // maybe? not really necessary with 271 already implemented, but probably a good idea for consistency with other APIs in the spec?
>     }
>
> This will not break backwards compatibility, since we are simply adding another injectable type for observer methods, and it is actually complimentary to the implementation provided in CDI-271, because we can now (through a null check,) determine if a bean was fired via an InjectionPoint or with the BeanManager. (But that could be backed out if we decide to go with the second method in the EventMetadata interface proposed above.)
>
> Thoughts?
>
> [0] https://issues.jboss.org/browse/CDI-271
> [1] https://issues.jboss.org/browse/CDI-36
> [2] https://issues.jboss.org/browse/CDI-71
>
> --
> Lincoln Baxter, III
> JBoss, by Red Hat
> lbaxter at redhat.com
>
> "If you want something, you'll find a way; if you don't, you'll find an excuse."
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev