Geoff, >From what I can see, it looks like the eventcache is just what I need. We have data in LDAP that is converted by generators into XML. I only want to do that when the data in LDAP changes. We manage that by having the wrapper around LDAP publish to a JMS topic when changes are made and the wrapper also listens. I have a Cocoon component that manages our access to LDAP via the wrapper and it listens for these events. I envision having my component generate the events that invalidate the cache.
Two questions. 1. Is eventcache stable enough for me to use or will it be undergoing radical changes? 2. From the vague description I have given does this sound like a "proper" usage of eventcache? Thanks, Ralph -----Original Message----- From: Geoff Howard [mailto:[EMAIL PROTECTED] Sent: Friday, February 27, 2004 9:49 AM To: [EMAIL PROTECTED] Subject: Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/cocoon/caching/impl StoreEventRegistryImpl.java DefaultEventRegistryImpl.java FYI I recently re-started making the StoreEventReg default, renaming DefaultEventReg, refactoring inheritance a little (pulled out an AbstractEventRegistry which both inherit from) etc. It's quite unfinished and I have close to no time right now for "play" but just wanted to give you a heads up that I have some refactor work going on. Next chance I get, I'll try to get it in a working state and either commit it or pass it on as a patch for someone else to pick up. I'd like to close the open bug about the serialized data location not being configurable but couldn't stand to hack in configuration when we've already agreed that some refactoring was needed. Don't quite get what was wrong before this commit by the way. Was this throwing an NPE all this time? (don't think so...) Geoff
