Hi!
I've just committed it. Please test it a little. I did a little stress
test with a pipeline that did an aggregate of around 100 parts
directly from the filesystem and serialized it to xml. The cached
response took 0-16 ms, while generating it took over 500 ms.
Be aware that the default cache key for all pipelines is the exact uri
you used to generate it. This has always been so with the
ExpiresCachingProcessingPipeline.
If you need to write your own (maybe your pipeline also depends on
session attributes or request parameters), use it like this:
<map:pipeline type="expires">
<map:parameter name="cache-key"
value="mycachekey-{0}-{request-param:myparam}-{session-attr:myattr}"/>
<map:match pattern="bla">
...
</map:match>
</map:pipeline>
Then the cache key will be of the same form for _all_ matchers within
this block. If you need another form (i.e. add/remove parameters), you
need to declare a nother pipeline element and give it a new
"cache-key" parameter.
By the way, "{0}" gives you the complete uri the matcher matched.
Have fun!
max
On 3/16/06, Ard Schrijvers <[EMAIL PROTECTED]> wrote:
>
> > Derek Hohls wrote:
> > > Any chance this will be in the forthcoming 2.1.9 release?
> >
> > I'm sat next to Ard right now so with a bit of luck, yes ;-)
> >
>
> Max is committing it. Should be available in 2.1.9
>
> AS
>
> --
>
> Hippo
> Oosteinde 11
> 1017WT Amsterdam
> The Netherlands
> Tel +31 (0)20 5224466
> -------------------------------------------------------------
> [EMAIL PROTECTED] / http://www.hippo.nl
> --------------------------------------------------------------
>
>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
