On Jun 8, 2011, at 7:56 AM, Gurkan Erdogdu wrote:

> Hello David
> 
> There are some cases that are explicitly defined in the specification. You 
> can 
> open TCK issue from CDI-TCK : https://issues.jboss.org/browse/CDITCK
> 
> Seems that our solution to find observer methods is correct!

That was my thought as well.  I can sort of see how it might be useful when 
looking at it from an overloaded method perspective:

   public void doit(Object o)
   public void doit(File f)

But I don't see any language like that in the spec anywhere.

I like our way better :)  Filed a JIRA

  https://issues.jboss.org/browse/CDITCK-215


-David

> ________________________________
> From: David Blevins <[email protected]>
> To: [email protected]
> Sent: Wed, June 8, 2011 1:01:54 PM
> Subject: Observer method resolution
> 
> Digging into a test that essentially has two observer methods and is 
> asserting 
> that only one of them are called.
> 
>   public void observeElephantSessionBean(@Observes 
> ProcessSessionBean<Elephant> 
> event)
>   {
>       ProcessBeanObserver.elephantProcessSessionBean = event;
>   }
>   
>   public void observeElephantBean(@Observes ProcessBean<Elephant> event)
>   {
>       ProcessBeanObserver.elephantProcessBeanCount++;
>   }
>   
> The test is asserting that observeElephantSessionBean is called and that 
> observeElephantBean is not called.
> 
> Currently we call both because ProcessSessionBean is assignable to 
> ProcessBean.
> 
> Anyone know what part of the spec might lead to this kind of requirement?  
> The 
> spec seems to say in 10.4 pretty clearly:
> 
>   There may be arbitrarily many observer methods with the same event 
> parameter 
> type and qualifiers.
>   A bean (or extension) may declare multiple observer methods.
> 
> 
> For the interested, the test is 
> org.jboss.jsr299.tck.tests.extensions.processBean.ProcessSessionBeanTest.testProcessSessionBeanEvent
> 
> 
> 
> -David

Reply via email to