Re: cvs commit: cocoon-2.1/src/blocks/eventcache/java/org/apache/ cocoon/caching/impl StoreEventRegistryImpl.java DefaultEventRegistryImpl. java

[Geoff Howard <co...@leverageweb.com>]

Ralph Goers wrote:

>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. 
>  
>

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:cocoon@leverageweb.com] 
>Sent:	Friday, February 27, 2004 9:49 AM
>To:	dev@cocoon.apache.org
>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
>
>
>
>  
>