On 13.04.2004 20:15, Windler Burri, Sarah wrote:

Hi
Last year we have built some very nice network applications with the
help of Cocoon V2.0.3. Thank you very much for this wonderful software.
I'd like to upgrade to Cocoon V2.1.4, but a problem has emerged:
The fragment extractor generates the first image in the right way, but
all following images have the data of the first one. The 'esql'-part
works all right.
In the mail archive I saw other programmers had the same problem.
<map:pipeline type="noncaching"> did not resolve the problem. I moved
from <map:action-set> to <map:action>, but this was not a help too.
Now, is it the cache of Cocoon or the FragmentExtractor.java class?

It's not the FragmentExtractor as this component - once configured - is cached and always valid. The javadoc says: "if the input is valid the output is valid as well." This is because the output will always be the same if the input is always the same.


Now this means you have to look on the input of the FragmentExtractor - or in other words on the components infront of it. For the stylesheet it's obviously the same as for the FragmentExtractor (valid input => valid output), so only XSP remains - and here my knowledge nearly ends, others might be of more help for you, but let me try.

Per default an XSP is not cacheable - what is a bit strange when reading your observations, or do you have made your XSP cacheable? At least for each different xsp output you need to return a different key in getKey() and for each output instance there is additionally a validity, which determines the ... yeah ... validity of the cache entry.

It's probably more obvious when explaining it with the file generator: the @src is the key, each file is an output instance and has its own cache validity. The validity is determined by the lastmodified value.

For more info on this have a look on the Cacheable XSP sample:
http://127.0.0.1:8888/samples/blocks/xsp/java/cacheable
the wiki:
http://wiki.cocoondev.org/Wiki.jsp?page=XSPCachingWithCocoonHEAD
and the official documentation:
http://cocoon.apache.org/2.1/userdocs/concepts/caching.html

Hopefully this helps, but I really wonder why your XSP is cacheable and pipeline noncaching does not help. Maybe it's not a problem of the caching itself, but the FragmentExtractor is not reset correctly. Can you test it with the log transformer by adding it before the FragmentExtractor and after it. If the output is the same for different inputs something is indeed wrong.

Joerg

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to