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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
