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

Lincoln Baxter lbaxter at redhat.com
Fri Mar 22 16:38:13 EDT 2013 

Pull request sent: https://github.com/jboss/cdi/pull/187

----- Original Message -----
From: "Lincoln Baxter" <lbaxter at redhat.com>
To: "Jozef Hartinger" <jharting at redhat.com>
Cc: "Lincoln Baxter, III" <lincolnbaxter at gmail.com>, "CDI-Dev" <cdi-dev at lists.jboss.org>
Sent: Wednesday, March 6, 2013 3:16:38 PM
Subject: Re: [cdi-dev] Problem with resolution of CDI-271 - Does not address original intent of issue (CDI-71)

   /**
    * 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 InjectionPoint getInjectionPoint(); // maybe? not really necessary with 271 already implemented, but probably a good idea for consistency with other APIs in the spec?

      /**
       * Returns the resolved event Type.
       */
      public Type getType();
   }

----- Original Message -----
From: "Jozef Hartinger" <jharting at redhat.com>
To: "Lincoln Baxter" <lbaxter at redhat.com>
Cc: "CDI-Dev" <cdi-dev at lists.jboss.org>, "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
Sent: Wednesday, March 6, 2013 3:06:53 PM
Subject: Re: [cdi-dev] Problem with resolution of CDI-271 - Does not address original intent of issue (CDI-71)

No, I meant java.lang.reflect.Type getType()

Inspecting payload would (due to type erasure) not give you all the type 
information. Since CDI 1.1 the type parameter of Event<?> may be used to 
infer the type parameters of the event payload. Therefore you can fire 
List<String> and it won't be delivered to List<Integer> observer.

Without the getType() method this information would be lost and e.g. a 
inter-CDI-container event routing solution would not work correctly.

On 03/06/2013 08:33 PM, Lincoln Baxter wrote:
>     /**
>      * Returns the Class<?> type of the fired event payload, as it was resolved by the event subsystem.
>      */
>     public Class<?> getType()
>
> Something like that? How would this work exactly? Just curious.
>
> In some cases this may be the same as the type of the observer method parameter, but in other cases, it may be a sub-type or even just Object.class. Right? Is that what you mean? I guess this could be handy since InjectionPoint may not always be available (reasonably.) But why couldn't the user just do type inspection on the object itself?
>
> ~Lincoln
>
> ----- Original Message -----
> From: "Jozef Hartinger" <jharting at redhat.com>
> To: "Lincoln Baxter" <lbaxter at redhat.com>
> Cc: "CDI-Dev" <cdi-dev at lists.jboss.org>, "Lincoln Baxter, III" <lincolnbaxter at gmail.com>
> Sent: Wednesday, March 6, 2013 2:02:54 PM
> Subject: Re: [cdi-dev] Problem with resolution of CDI-271 - Does not address original intent of issue (CDI-71)
>
> 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

_______________________________________________
cdi-dev mailing list
cdi-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev

More information about the cdi-dev mailing list