On 11/23/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote: > > > 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
Gotcha. If you have a need for this now, great - seems like maybe YAGNI would apply otherwise. > 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. Ah, right (memory's not as bad as I thought). So if you wanted a more generic implementation of an EventAware component that wasn't a Cache or Store, you'd still have to rely on the "eventaware" cache block, and probably would have a event-based cache set up in your .xconf though you may not need it. No biggie for now. > I just don't see how you can use the eventcache or "eventaware" block without > needing the jms block... at least right now. Well, the eventcache block works now without JMS. You can have http-based events (the sample does this). Before my work on this there was (and maybe still is) a commercial cocoon add-on which did something similar using database triggers in Oracle to access URLs to do just this - without JMS. Can't remember the name at the moment. Also, at the time I was also working on a filesytem listener to listen to OS-specific events at the file system level to let you do your uncaching automatically only when files were updated, without polling. IIRC, Windows, Linuxes, and Solaris all supported the basic plumbing to allow this to happen with some native code. So that would just need eventcache block without JMS. > 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? That might be necessary, but I'd suggest leaving it be for now. > > Anyway, it's almost certainly not important to consider at the moment. > > Okay. > > Am I ready to roll, then? > > max I'd say so! Geoff
