Geoff,
From what I can see, it looks like the eventcache is just what I need. Wehave 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.
Really your component would translate the JMS messages to the Event and handle the contact with the EventCacheImpl. Depending on the complexity of that translation, you could be able to use the JMSEventListener already in the jms block as is. Otherwise, it's pretty simple to implement fresh.
Two questions.
1. Is eventcache stable enough for me to use or will it be undergoing
radical changes?
That's a good question. It's still marked alpha/stable/whatever but that is more by inaction than purposeful decision (at least on my part). Of course it's up to the larger community but it's been mostly Unico and myself that have worked on it. Practically, I'd feel more comfortable having heard from more people who have used it before locking it down - so your use could contribute to its stability.
Having said that, it's a simple API and shouldn't need much tweaking. In fact, the part of the API you would rely on is two _very_ simple interfaces (Event and EventAware). The only thing I ever imagined affecting that is a feature I envisioned originally ("wildcard" events) but which never came to pass. I have since wondered whether they would be all that useful and now feel they could probably be implemented in a back-compatible way anyway. Originally I was questioning the use of Map based hash lookup for events because that would (probably) not support wildcards.
Maybe we should consider marking the block "stable"?
2. From the vague description I have given does this sound like a "proper"
usage of eventcache?
Yes, it sounds spot on.
Geoff
-----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
