cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: Fragment Extractor and Cache in V2.1.4
Date Tue, 13 Apr 2004 22:47:56 GMT
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 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:
the wiki:
and the official documentation:

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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message