On 11/23/05, Max Pfingsthorn <[EMAIL PROTECTED]> wrote: > > 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.
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". > > WDYT? 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 yet. Anyway, it's almost certainly not important to consider at the moment. Geoff
