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
