RE: event aware object cache?
Geoff Howard [mailto:[EMAIL PROTECTED] wrote: On 11/21/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Hi Cocooners! I have a question: I couldn't find a nice EventAware object cache in Cocoon, the eventcache block only implements the o.a.c.caching.Cache which I need to pass a byte array. Serializing/deserializing is not really an option for me. What I would like is a (not necessarily persistent) EventAware cache for objects used for form my responses of a generator. I could imagine that this sort of cache might be useful for others as well. If so, and it is not implemented yet, I would like to go ahead and do so. WDYT? Does anyone have any pointers for me? Hmm, it's been a while since I've looked at this and the code base WRT the Cache/Store code has changed since in a way I didn't keep fully abreast of. The original intention of the EventAware code was to do exactly what you wanted. IIRC the Cache used to have a transient front-end backed by a persistent backend transparently. Since then the terminology and code was changed I think to have Stores be transient and Cache persistent. I see, so your suggestion would be to implement an EventAware MRUMemoryStore? And maybe also make the EHDefaultStore EventAware? I guess for that, an EventAwareManager would be required cause right now the JMSEventMessageListener looks up the EventAware cache by itself instead of getting a list of EventAwares and calling processEvent on them. One big problem though: Stores are deprecated... :( For your need, it may only be necessary to factor the relevant code out of the Cache to a more generic place where both Store and Cache can take advantage of it. Not sure if that is necessary. I can see that the functionality is rather the same, but making a wrapper around the ehcache Cache or something like that seems a little weird cause we would dictate which cache implementation to use. Maybe the EventAware interface is enough, but add a manager for them? I guess we could provide ready wrappers around different implementations, WDYT? I can't give it a lot of time at the moment, but do want to help make sure this is generally useful. Can you provide some more details of the problem as it exists now to help me get up to speed quickly? My problem is that I need to generate xml ( obviously ;) ), but the xml tree represents a directory tree on a webdav server. So, I don't need to walk over all collections to generate my xml, just over the ones that changed. For that, I'd like to keep two things in memory: A list of children per node and a set of attributes per node. These might not be Serializable (right now I just stuff the AttributesImpl object into a map)... So, what I want is a way to remove these two from the cache/store if a corresponding event comes in so they are regenerated, but I don't have to rebuild the complete structure. 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. WDYT? max
Re: event aware object cache?
On 11/23/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Geoff Howard [mailto:[EMAIL PROTECTED] wrote: On 11/21/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Hi Cocooners! I have a question: I couldn't find a nice EventAware object cache in Cocoon, the eventcache block only implements the o.a.c.caching.Cache which I need to pass a byte array. Serializing/deserializing is not really an option for me. What I would like is a (not necessarily persistent) EventAware cache for objects used for form my responses of a generator. I could imagine that this sort of cache might be useful for others as well. If so, and it is not implemented yet, I would like to go ahead and do so. WDYT? Does anyone have any pointers for me? Hmm, it's been a while since I've looked at this and the code base WRT the Cache/Store code has changed since in a way I didn't keep fully abreast of. The original intention of the EventAware code was to do exactly what you wanted. IIRC the Cache used to have a transient front-end backed by a persistent backend transparently. Since then the terminology and code was changed I think to have Stores be transient and Cache persistent. I see, so your suggestion would be to implement an EventAware MRUMemoryStore? And maybe also make the EHDefaultStore EventAware? I guess for that, an EventAwareManager would be required cause right now the JMSEventMessageListener looks up the EventAware cache by itself instead of getting a list of EventAwares and calling processEvent on them. One big problem though: Stores are deprecated... :( I missed the deprecation of the Stores discussion. Do you have some pointers in the dev list archives? 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? For your need, it may only be necessary to factor the relevant code out of the Cache to a more generic place where both Store and Cache can take advantage of it. Not sure if that is necessary. I can see that the functionality is rather the same, but making a wrapper around the ehcache Cache or something like that seems a little weird cause we would dictate which cache implementation to use. Maybe the EventAware interface is enough, but add a manager for them? I guess we could provide ready wrappers around different implementations, WDYT? I can't give it a lot of time at the moment, but do want to help make sure this is generally useful. Can you provide some more details of the problem as it exists now to help me get up to speed quickly? My problem is that I need to generate xml ( obviously ;) ), but the xml tree represents a directory tree on a webdav server. So, I don't need to walk over all collections to generate my xml, just over the ones that changed. For that, I'd like to keep two things in memory: A list of children per node and a set of attributes per node. These might not be Serializable (right now I just stuff the AttributesImpl object into a map)... So, what I want is a way to remove these two from the cache/store if a corresponding event comes in so they are regenerated, but I don't have to rebuild the complete structure. 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. Geoff
RE: event aware object cache?
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
Re: event aware object cache?
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
RE: event aware object cache?
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 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! :) WDYT? Anyway, it's almost certainly not important to consider at the moment. Okay. Am I ready to roll, then? max [1] http://www.scit.wlv.ac.uk/~jphb/comms/iproute.html
Re: event aware object cache?
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
RE: event aware object cache?
Geoff Howard [mailto:[EMAIL PROTECTED] wrote: ... 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. Yeah.. Had a slight ring of overkill to it... ... Am I ready to roll, then? max I'd say so! Great! I'll keep you posted on my progress :) max
Re: event aware object cache?
On 11/21/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Hi Cocooners! I have a question: I couldn't find a nice EventAware object cache in Cocoon, the eventcache block only implements the o.a.c.caching.Cache which I need to pass a byte array. Serializing/deserializing is not really an option for me. What I would like is a (not necessarily persistent) EventAware cache for objects used for form my responses of a generator. I could imagine that this sort of cache might be useful for others as well. If so, and it is not implemented yet, I would like to go ahead and do so. WDYT? Does anyone have any pointers for me? Hmm, it's been a while since I've looked at this and the code base WRT the Cache/Store code has changed since in a way I didn't keep fully abreast of. The original intention of the EventAware code was to do exactly what you wanted. IIRC the Cache used to have a transient front-end backed by a persistent backend transparently. Since then the terminology and code was changed I think to have Stores be transient and Cache persistent. For your need, it may only be necessary to factor the relevant code out of the Cache to a more generic place where both Store and Cache can take advantage of it. I can't give it a lot of time at the moment, but do want to help make sure this is generally useful. Can you provide some more details of the problem as it exists now to help me get up to speed quickly? Thanks, Geoff
