cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: event aware object cache?
Date Wed, 23 Nov 2005 14:22:50 GMT
On 11/23/05, Max Pfingsthorn <> wrote:
> Geoff Howard [] wrote:
> > On 11/23/05, Max Pfingsthorn <> wrote:
> > >
> > > Geoff Howard [] wrote:
> > > > On 11/21/05, Max Pfingsthorn <> wrote:
> ...
> >
> > I missed the deprecation of the Stores discussion. Do you have some
> > pointers in the dev list archives?
> Oh, no, nevermind. The Store interfaces moved into excalibur(?), but the stores in general
aren't deprecated... My mistake.

Ah, good.  I didn't think I could miss something that big, but you never know.

> > 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".

Yes, that sounds about right though I haven't fully thought it through.

> ...
> > > 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

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


View raw message