Geoff Howard [mailto:[EMAIL PROTECTED] wrote: > On 11/23/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote: > > > > Geoff Howard [mailto:[EMAIL PROTECTED] wrote: > > > On 11/21/05, Max Pfingsthorn <[EMAIL PROTECTED]> 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. > > 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? ... > > 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? max
