Hi Bertrand, > but did you look at the > "cacheable" sample of the XSP block?
yes, it seems not to do more than I do in my generator (i.e. setting the getKey and getValidity methods. The only way I have found to have cache working is to set the transformers as "non-cacheable". But this makes cocoon to cache only the generator (or up to the first non-cacheable transformer) and nothing else. For this reason I have to use the "caching-point" feature (I have to cache the complete response and the generator both). Debugging I've seen the parameter I've set is read and the object has the correct value after the parameters parsing. I also know that two results are stored in the cache, one for the complete response and one (I guess) for the partial result at the point marked by the parameter. But when the second request (with a different view) is received, cocoon first check for a result matching the key of the complete response (keys are build as a list of the key from the generator to the serializer) and of course it doesn't find it. Then it removes the keys from the list up to the "caching-point" and then it should check again for a match in the cache and (I guess) if there is one connect the pipeline between the correct producer/consumer pair. Well, this second check seems to fail and I don't understand way. All the joke is made in four java classes but methods are called ina fashion that it's not very easy to understand (...ok, I'm not a cocoon guru :-) ). I'll try to debug it again. I need that because we are developing an opensource opac. bye, romano
