One is implemented in part in the event-cache block but it could be generalized to work for any component. Unico Hommes wrote a Generator (in that block, but don't know its name) which uses a Delegation pattern to wrap any other arbitrary Generator. It delegates all interface methods to the wrapped generator except for the get Validity (and currently the key as well, but I think that might need to change. He then uses a factory which specifies how to construct the overridden validity. The plan was to generalize this to work with any component. Hope that makes sense.
The second possibly simpler solution is to create a new pipeline implementation that always caches. So, when you have a pipeline that should be forced to cache, you segregate it into its own map:pipeline section with a parameter that speficies how long to cache.
A third is to consider the event based cache stuff itself.
Geoff
Gianugo Rabellino wrote:
Sorry for the late reply. Vacation time + lousy GPRS + heavy spam/worm activities nearly killed my ability to read email.
Miles Elam wrote:
I'm running into a snag and was wondering if anyone had some wisdom to grant to me. The current behavior of caching pipelines is to aggregate the keys of all cacheable pipeline components and use them as the cache hash lookup. In the case of a pipeline that has uncacheable components but has an expiry, this scheme doesn't work: the key is incomplete or nonexistent. My first thought was to use the request URI but therein lies the snag; Any actions or selectors in use that would fundamentally alter the request would be erroneously cached. In 90% of the cases, I don't see this as a problem. But in cases like when different formats are sent to different clients for the same URI
Yes, this was exactly my showstopper when I tried to quickly force caching uncacheable stuff. I really need to catch up on caching internals as it's been a few months since I looked at it, but I was kinda of planning to add a fake cache key for each component in the pipeline which is uncacheable. The problem is coming up with a syntax that is reversible, so that the resulting key can be successfully looked up.
The trick should lie somewhere in o.a.c.components.pipeline.impl.AbstractCachingProcessingPipeline#generateCachingKey(): there should be, in particular, some kind of surrogate that returns a key for each non cacheable component. I'm still uncertain whether this key should be unique (based, i.e., on the positional parameter of the component in the sitemap) or if a simple label could work. I'm for the latter ATM: of course I need to check it out, but the following snippet (extended to transformers & serializer) might work.
// is the generator cacheable? if (super.generator instanceof CacheableProcessingComponent) { key = ((CacheableProcessingComponent)super.generator).getKey(); this.generatorIsCacheableProcessingComponent = true; } else if (super.generator instanceof Cacheable) { key = new Long(((Cacheable)super.generator).generateKey()); } else if (expires != 0) { // Component is not cacheable, but an explicit expires // was set. Provide a fake cache key. key = new String("Forced-Expires"); }
Doing so, we would end up with a PipelineCacheKey that's made up of different caching keys, some of which are real and some of which are just placeholders. I'm going to try this path and see what comes out of it.
Ciao,
