You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Gernot Koller <ge...@gmx.at> on 2003/12/18 20:33:18 UTC
Migration Problems 2.1.2 -> 2.1.3 eventcache and headerselector
Hi
In my application I use the following pipeline fragment:
<map:select type="header">
<map:parameter name="header-name" value="X-Cocoon-Portal" />
<map:when test="true">
<map:transform type="rsf_components">
<map:parameter name="components" value="portal" />
</map:transform>
<map:serialize type="xml" />
</map:when>
<map:otherwise>
<map:transform type="rsf_components" />
<map:serialize type="html" />
</map:otherwise>
</map:select>
what it should do is: when ever the http header X-Cocoon-Portal is set to
'true' it should invoke the "rsf_components" transformer with a special
parameter and serialize xml content.
If the header is not set it should invoke the transformer without the
parameter and serialize html.
This works as expected using Cocoon 2.1.2.
After migrating to cocoon 2.1.3 it stopped working and it seemed that always
the 'otherwise' path was executed regardeless of any header values.
After some painfull hours of "debugging" I could track it down to the these
two lines in the cocoon.xconf:
<!--..... Start configuration from 'eventcache' -->
<component class="org.apache.cocoon.caching.impl.EventAwareCacheImpl"
role="org.apache.cocoon.caching.Cache/EventAware"/>
<!--..... End configuration from 'eventcache' -->
<!--..... Start configuration from 'eventregistry' -->
<component class="org.apache.cocoon.caching.impl.DefaultEventRegistryImpl"
role="org.apache.cocoon.caching.EventRegistry"/>
<!--..... End configuration from 'eventregistry' -->
With these two lines in the cocoon.xconf the behaviour is wrong, without
them everythings seems to work be allright.
I do not have much of an idea what these two lines really do but it seems to
have something to do with caching.
Maybe the problem is that the request without headerparameter has been
cached and sending a request with the headerparameter still fetches the old
(wrong) result from the cache.
This is just me speculating, but it would explain what I'm experiencing.
Actually I have no problems leaving out these two lines in the cocoon.xconf
but I have no idea what consequences this might have. I definitly don't want
to disable caching totaly and the shown pipeline fragment is part of the
resource every single request of my application uses for rendering.
By the way if anybody has a better method of migrating the cocoon.xconf file
from one version to the next, than the poor heuristics that I use, please
enlighten me !!
Thanks for your input,
Gernot
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Migration Problems 2.1.2 -> 2.1.3 eventcache and headerselector
Posted by Geoff Howard <co...@leverageweb.com>.
Gernot Koller wrote:
> Hi
>
> In my application I use the following pipeline fragment:
>
> <map:select type="header">
> <map:parameter name="header-name" value="X-Cocoon-Portal" />
> <map:when test="true">
> <map:transform type="rsf_components">
> <map:parameter name="components" value="portal" />
> </map:transform>
> <map:serialize type="xml" />
> </map:when>
> <map:otherwise>
> <map:transform type="rsf_components" />
> <map:serialize type="html" />
> </map:otherwise>
> </map:select>
>
> what it should do is: when ever the http header X-Cocoon-Portal is set to
> 'true' it should invoke the "rsf_components" transformer with a special
> parameter and serialize xml content.
> If the header is not set it should invoke the transformer without the
> parameter and serialize html.
>
> This works as expected using Cocoon 2.1.2.
> After migrating to cocoon 2.1.3 it stopped working and it seemed that always
> the 'otherwise' path was executed regardeless of any header values.
>
> After some painfull hours of "debugging" I could track it down to the these
> two lines in the cocoon.xconf:
>
> <!--..... Start configuration from 'eventcache' -->
> <component class="org.apache.cocoon.caching.impl.EventAwareCacheImpl"
> role="org.apache.cocoon.caching.Cache/EventAware"/>
> <!--..... End configuration from 'eventcache' -->
> <!--..... Start configuration from 'eventregistry' -->
> <component class="org.apache.cocoon.caching.impl.DefaultEventRegistryImpl"
> role="org.apache.cocoon.caching.EventRegistry"/>
> <!--..... End configuration from 'eventregistry' -->
>
> With these two lines in the cocoon.xconf the behaviour is wrong, without
> them everythings seems to work be allright.
> I do not have much of an idea what these two lines really do but it seems to
> have something to do with caching.
This is really, really bizarre for a couple of reasons.
- First, the EventAwareCache should not even be used on your pipeline
unless explicitly configured to do so. Can you send the part of your
sitemap that defines this pipeline (<map:pipeline...>)? The fact that
removing those lines from cocoon.xconf "fixes" the problem and doesn't
totally break the pipeline is a sign that this is not the case..
- Second, unless any of the components you are using define "event
aware" validities, the EventAware Cache should ignore them and let the
normal cache impl handle them. You don't give the generator part of
this pipeline - that could give a clue.
Now, the portal uses some of its own caches and it is possible that
something is going haywire there. Try using the selector with a
different header not in the context of the portal. User agent might be
an easy one - you could just use two different browsers. Alternatively,
if you use mozilla I think you can get a plugin (liveHeaders?) to let
you edit the headers your browser sends for a request. Another option
is to use this little app a friend made:
http://www.networksimplicity.com/utils/ (look for TelHelper). If this
only happens on Portal requests but not with other headers, we'll have
to consult with Carsten.
However, I am most suspicious that this has something to do with the
upgrade process from 2.1.2-2.1.3 and is not necessarily a behavior that
would be replicated in a fresh install. Can you try to confirm that?
First step would be to confirm that removing them fixes the problem and
putting them back in breaks it again. Then, with a fresh build of 2.1.3
try to create a minimal test pipeline. If it still always fails, send
me the test pipeline and anything I'll need to replicate it here.
> Maybe the problem is that the request without headerparameter has been
> cached and sending a request with the headerparameter still fetches the old
> (wrong) result from the cache.
> This is just me speculating, but it would explain what I'm experiencing.
That's reasonable, but the way the caching is supposed to work is this:
1) All sitemap elements which help to determine pipeline setup are
executed (selectors, matchers, actions, flowscripts).
2) Once a generator-transformer*-serializer pipeline set is constructed,
each element is asked to generate a pipeline key based on whatever
criteria it chooses which will uniquely identify the content it would
create if asked to do so. (i.e., if a generator makes different content
for each src attribute, but no other factor influences the content, it
should only look at and use the src attribute in constructing the key).
3) Using the aggregated key, the cache is searched for a matching entry.
4) If found, the cached entry has each validity examined to determine if
the cached response is still valid.
5) If still valid it's returned - if not, it's discarded and the
pipeline is executed again.
Now, in your case, the two pipelines are not identical (different
serializer, and different parameter to the transformer) so the cached
response for "otherwise" should not even enter the picture because it
shouldn't be returned from the cache lookup.
> Actually I have no problems leaving out these two lines in the cocoon.xconf
> but I have no idea what consequences this might have. I definitly don't want
> to disable caching totaly and the shown pipeline fragment is part of the
> resource every single request of my application uses for rendering.
If you're looking for the easy way out, just leave those lines out of
cocoon.xconf. They are not the caching mechanism itself but an
extension to it which allows caching of content until an external event
is triggered, such as a database update. There are some samples in the
eventcache block and the jms block which should make it clearer if
you're interested.
> By the way if anybody has a better method of migrating the cocoon.xconf file
> from one version to the next, than the poor heuristics that I use, please
> enlighten me !!
Yes, Ralph's post about using the xpatch ant task (which is much easier
to use in ant by the way!) is my recommendation. Do not hand edit the
various conf files (cocoon.xconf, web.xml, etc.). Create "patch" files
which can be run against the default cocoon files to get you back to
square one automatically on a version upgrade. It's described here:
http://wiki.cocoondev.org/Wiki.jsp?page=ProjectBuilding
http://wiki.cocoondev.org/Wiki.jsp?page=XPatchTaskUsage
http://wiki.cocoondev.org/Wiki.jsp?page=CustomConfigTarget and
http://wiki.cocoondev.org/Wiki.jsp?page=YourCocoonBasedProject
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Migration Problems 2.1.2 -> 2.1.3 eventcache and headerselector
Posted by Gernot Koller <ge...@gmx.at>.
Thanks Ralph and Geoff for your quick and competent replys!
The problem is solved now and the two lines in the cocon.xconf actually had
nothing to do with it.
Seems that I have been fooled by some other caching (probably the ie cache).
Thanks especially for the links to the wiki pages I will work them trough!
lg,
Gernot
--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Migration Problems 2.1.2 -> 2.1.3 eventcache and headerselector
Posted by Geoff Howard <co...@leverageweb.com>.
Gernot Koller wrote:
> Hi
>
> In my application I use the following pipeline fragment:
>
> <map:select type="header">
> <map:parameter name="header-name" value="X-Cocoon-Portal" />
> <map:when test="true">
> <map:transform type="rsf_components">
> <map:parameter name="components" value="portal" />
> </map:transform>
> <map:serialize type="xml" />
> </map:when>
> <map:otherwise>
> <map:transform type="rsf_components" />
> <map:serialize type="html" />
> </map:otherwise>
> </map:select>
>
> what it should do is: when ever the http header X-Cocoon-Portal is set to
> 'true' it should invoke the "rsf_components" transformer with a special
> parameter and serialize xml content.
> If the header is not set it should invoke the transformer without the
> parameter and serialize html.
>
> This works as expected using Cocoon 2.1.2.
> After migrating to cocoon 2.1.3 it stopped working and it seemed that always
> the 'otherwise' path was executed regardeless of any header values.
>
> After some painfull hours of "debugging" I could track it down to the these
> two lines in the cocoon.xconf:
>
> <!--..... Start configuration from 'eventcache' -->
> <component class="org.apache.cocoon.caching.impl.EventAwareCacheImpl"
> role="org.apache.cocoon.caching.Cache/EventAware"/>
> <!--..... End configuration from 'eventcache' -->
> <!--..... Start configuration from 'eventregistry' -->
> <component class="org.apache.cocoon.caching.impl.DefaultEventRegistryImpl"
> role="org.apache.cocoon.caching.EventRegistry"/>
> <!--..... End configuration from 'eventregistry' -->
>
> With these two lines in the cocoon.xconf the behaviour is wrong, without
> them everythings seems to work be allright.
> I do not have much of an idea what these two lines really do but it seems to
> have something to do with caching.
>
> Maybe the problem is that the request without headerparameter has been
> cached and sending a request with the headerparameter still fetches the old
> (wrong) result from the cache.
> This is just me speculating, but it would explain what I'm experiencing.
>
> Actually I have no problems leaving out these two lines in the cocoon.xconf
> but I have no idea what consequences this might have. I definitly don't want
> to disable caching totaly and the shown pipeline fragment is part of the
> resource every single request of my application uses for rendering.
>
> By the way if anybody has a better method of migrating the cocoon.xconf file
> from one version to the next, than the poor heuristics that I use, please
> enlighten me !!
>
> Thanks for your input,
>
> Gernot
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org