Hi Mark,
Thanks for your help. I like your test case -- it
simpler and cleaner. Do you (or anyone else) know how
to submit this as a bug to make sure the developers
know about it?
Cheers,
-Alex
--- Mark H <[EMAIL PROTECTED]> wrote:
> I tried out a simpler form: (don't have the source
> code for your
> actions/stylesheets)
>
> <map:components>
> <map:actions>
> <map:action name="request"
> src="org.apache.cocoon.acting.RequestParamAction"/>
> </map:actions>
> </map:components>
> <map:pipelines>
> <map:pipeline>
> <map:match pattern="*.portlet">
> <map:match pattern="a.portlet">
> <map:generate src="cocoon:/a.resource"/>
> <map:serialize type="xml"/>
> </map:match>
> </map:match>
> <map:match pattern="*.resource">
> <map:match pattern="a.resource">
> <map:act type="request">
> <map:parameter name="parameters" value="true"/>
> <map:generate src="{locale}.xml"/>
> <map:serialize type="xml"/>
> </map:act>
> </map:match>
> </map:match>
> </map:pipeline>
> </map:pipelines>
>
> and got the same caching problem you got, can
> anybody try the above in
> v2.0.4 to see if it is a 2.1 bug?
>
> when I did the following it worked ok:
>
> <map:match pattern="*.portlet">
> <map:match pattern="a.portlet">
> <map:act type="request">
> <map:parameter name="parameters" value="true"/>
> <map:generate src="{locale}.xml"/>
> <map:serialize type="xml"/>
> </map:act>
> </map:match>
> </map:match>
>
> It seems to be caching cocoon:/a.resource. I can't
> see exactly what it's
> doing because it's not generating any logs (it
> should log caching in
> sitemap.log). I'm also having problems with the
> latest CVS it seems to be in
> a state of flux. The only way to fix these problems
> is to go deep into the
> Cocoon's/Avalon/Excalibur source code and debug.
>
> -----Original Message-----
> From: Alex Romayev [mailto:[EMAIL PROTECTED]
> Sent: 03 March 2003 02:57PM
> To: [EMAIL PROTECTED]
> Subject: Very strange behaviour -- caching bug?
>
>
> Hello,
>
> There is a very strange behaviour that my site
> exibits
> ever since I've upgraded my 2.1 dev code from what
> it
> was in Nov-Dec last year to the most current version
> (less than a week old).
>
> Here is what's going on. There is a portlet which
> is
> generated by calling another pipeline fragment
> matching "a.resource". It looks like a.resource
> behaves correctly, however it seems that a.portlet,
> which uses a.resource as its input does not realize
> when a.resource's output changes and keeps working
> with the incorrect cached version.
>
> The following works correctly:
> http://localhost:8080/cocoon/a.resource?locale=en
> - displays output in English
> http://localhost:8080/cocoon/a.resource?locale=ru
> - displays output in Russian
>
> Still fine:
> http://localhost:8080/cocoon/a.portlet?locale=en
> - displays output in English
>
> PROBLEM:
> http://localhost:8080/cocoon/a.portlet?locale=ru
> - displays output in ENGLISH!
>
> If I "touch" a.xsl in the following pipeline, and
> hence, force the reload, everything works fine,
> however when I change locale, it's back to the
> behaviour I've just described.
>
> The following is a simplified pipeline:
>
> <map:pipeline>
> <map:match "*.portlet">
> <map:match "a.portlet">
> <map:generate src="cocoon:/a.resource"/>
> <map:transform src="a.xsl"/>
> <map:serialize type="xml"/>
> </map:match>
> </map:match>
> </map:pipeline>
>
> <map:pipeline>
> <map:match "*.resource">
> <map:match "a.resource">
> <map:generate src="a.xml"/>
> <map:act type="locale">
> <map:transform type="i18n">
> <map:parameter name="locale"
> value="{locale}"/>
> </map:transform>
> </map:act>
> <map:serialize type="xml"/>
> </map:match>
> </map:match>
> </map:pipeline>
>
> Cheers,
> -Alex
>
>
---------------------------------------------------------------------
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
