cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Pfingsthorn" <>
Subject RE: event aware object cache?
Date Wed, 23 Nov 2005 16:55:42 GMT

Geoff Howard [] 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
*      | barr  | baz     << baz should also get any message with topic barr from any
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! :)


> Anyway, it's almost certainly not important to consider at the moment.


Am I ready to roll, then?



View raw message