Geoff Howard [mailto:[EMAIL PROTECTED] wrote: ... > > > Would it be sufficient to configure JMSEventMessageListener with a > > > list of EventAwares? If the EAManager is necessary, I > guess it would > > > have to be configured with such a list unless you can > think of a way > > > for it to discover all EventAwares in the system? > > > > Well, I was thinking of registering event awares with that > manager so its more up to the components... Then again, if > you have multiple jms providers, you might want to listen to > a specific topic, or only forward events to a subset of EAs... > > Its hard to do this kind of thing with lookup IoC. > > Also, its a tradeoff between configuring the connections > between source and sink of the events (e.g. the path between > the jms listener and the cache) as roles to look up or as > some sort of routing configuration. > > We could do this by: > > 1. Letting event awares choose sources/topics to listen to > > 2. Configuring a name per event source > > > > Then, a listener can say, I want to listen to topic "foo", > no matter where from, or even listen to "bar" only from > source "baz" and "bas". > > > > WDYT? > > Yes, that sounds about right though I haven't fully thought > it through.
Okay. What about routing tables? Like the one shown under "Internet Routing - Internal Routing Tables" in [1], we could make a list of "routing rules": Source | Topic | Listener ------------------------- foo | bar | baz << means topic bar from source foo should be delivered to listerner baz * | barr | baz << baz should also get any message with topic barr from any source foo | * | foolist << foolist listens to any topic from source foo foo | bing | * << foo distributes any "bing" message to any listener foobar | * | * << foobar distributes any message to any listener * | bang | * << bang messages are always delivered to all listeners from any source * | * | bazz << bazz listens to any message Now, this table can be configured for the EventAwareManager in cocoon.xconf. I would also add methods such that listeners can add/remove rules, or have some way to do this during runtime in any case. Maybe with an interface using cforms? :D Covers all cases, right? > > > ... > > > > Another usecase in favor of having a general > > > EventAwareManager to keep track of EventAware instances would > > > be to have a way to notify a business object model when the > > > backend changes, or generally notify it via JMS. We'll be > > > running into that soon over here, so it would be nice to get > > > some ground work done. > > > > > > That is outside the original intention but should work. > There may be > > > some odd block dependencies if someone wants to do that > but not use an > > > EventAwareCache, they could wind up requiring both the > JMS block and > > > the EventAware block anyway. If you can see a way to allow your > > > use-case but avoid that false dependency, that'd be great. > > > > I don't really see that problem as you still have to > configure which cache to use in your cocoon.xconf. Otherwise, > if you want to use jms/eventaware, of course you need both > blocks... I don't really understand the false dependency, can > you explain? > > I thought I had remembered that the EventAware interfaces and > implementations were all in the two blocks, but now that I think of > it, I guess EventAware itself is in core? I just switched to a new > laptop recently and don't even have a local copy of the source on it > yet. EventAware, EventAwareCacheImpl, EventRegistry, JMSEventMessageListener, etc are all in the eventcache block. JMSEventMessageListener extends AbstractMessageListener from the jms block. I just don't see how you can use the eventcache or "eventaware" block without needing the jms block... at least right now. Maybe we can factor out an interface for a generic "EventSource" which associates with the "EventAwareManager" (or maybe "EventMultiplexer"?) to deliver events? Then the jms block can provide a jms implementation of it (the JMSEventMessageListener) and there you go, blocks decoupled! :) WDYT? > > Anyway, it's almost certainly not important to consider at the moment. Okay. Am I ready to roll, then? max [1] http://www.scit.wlv.ac.uk/~jphb/comms/iproute.html
