[weld-dev] External Event Routing

[Gavin King]

Right.

Sent from my iPod

On Jan 27, 2010, at 3:08 AM, David Allen <drallendc at gmail.com> wrote:

> Jordan,
>
> You would not inject the qualifiers, but would use CDI extensions to  
> add
> your own ObserverMethod to provide the bridge needed between CDI  
> events
> and some other event infrastructure.
>
> You just simply add the new ObserverMethod during the  
> AfterBeanDiscovery
> event (11.5.2) and then with Gavin's suggested change to the signature
> of notify(), you would then have all the qualifiers that are present  
> on
> that given event.
>
> - David
>
> On Wed, 2010-01-27 at 00:33 -0500, Jordan Ganoff wrote:
>> ObserverMethod.notify(T, Set<Annotation>) might work.  It seems
>> minimalistic and would be optionally injected.  I've made the  
>> relevant
>> code changes to support this; however, I'm not sure the best way to
>> implement the actually injection of Set<Annotation> on an observer
>> method. e.g. void onEvent(@Observes String s, Set<Annotation>
>> qualifiers, <other injection point references>)
>>
>>
>> Would it be useful for MethodInjectionPoint to define
>> invokeOnInstanceWithSpecialValue(..) allowing more than one special
>> value so the qualifiers could be provided directly?
>>
>>
>> Is there a better way to provide the qualifier set as a parameter?
>>
>>
>>
>>
>> On Mon, Jan 25, 2010 at 8:37 PM, Gavin King <gavin.king at gmail.com>
>> wrote:
>>        I think the real problem is with the signature of the notify()
>>        method
>>        of this interface:
>>
>>        http://docs.jboss.org/cdi/api/1.0/
>>
>>
>>        On Mon, Jan 18, 2010 at 9:49 PM, Jordan Ganoff
>>        <jganoff at gmail.com> wrote:
>>> Just brainstorming here but:
>>> 1) Methods could observe the raw Event<Type> to receive all
>>        events of that
>>> type.  Then Event would need to expose the qualifiers
>>        publicly - maybe as
>>> high up as AbstractFacade?
>>> Something like:  public void allStrings(@Observes
>>        Event<String> event);
>>> 2) Allow registration of a new interface:  EventHandler.
>>> BeanManager.fireEvent() would be required to fire the event
>>        on all
>>> registered handlers.  The current event observer resolver
>>        would be the first
>>> implementation of this.
>>> 3) Same idea as #2 but restricted to Portable Extensions.
>>> Good/bad?
>>>
>>> On Mon, Jan 18, 2010 at 5:36 PM, Gavin King
>>        <gavin.king at gmail.com> wrote:
>>>>
>>>> Hrm. That's true. That's on oversight. Do you have a
>>        proposed solution
>>>> to this problem? I would be open to addressing this issue
>>        in the CDI
>>>> MR.
>>>>
>>>> On Sun, Jan 17, 2010 at 11:19 AM, Jordan Ganoff
>>        <jganoff at gmail.com> wrote:
>>>>> I'm trying to route Events from a portable extension (to
>>        be the Seam 3
>>>>> JMS
>>>>> module).  After talking to David Allen it seems there is
>>        currently no
>>>>> way to
>>>>> get the qualifiers for a fired event.  Without the
>>        qualifiers it doesn't
>>>>> seem like routing outside of Weld-core is possible.  The
>>        idea of using
>>>>> an
>>>>> Interceptor on BeanManager.fireEvent() would have worked
>>        but we can't
>>>>> assign
>>>>> Interceptors to an existing class.
>>>>> Any ideas?
>>>>> --
>>>>> Jordan Ganoff
>>>>> _______________________________________________
>>>>> weld-dev mailing list
>>>>> weld-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Gavin King
>>>> gavin.king at gmail.com
>>>> http://in.relation.to/Bloggers/Gavin
>>>> http://hibernate.org
>>>> http://seamframework.org
>>>
>>>
>>
>>
>>
>>
>>        --
>>
>>        Gavin King
>>        gavin.king at gmail.com
>>        http://in.relation.to/Bloggers/Gavin
>>        http://hibernate.org
>>        http://seamframework.org
>>
>>
>>
>>
>> -- 
>> Jordan Ganoff
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>