[
http://issues.apache.org/jira/browse/COCOON-1681?page=comments#action_12364075
]
Antonio Fiol commented on COCOON-1681:
--------------------------------------
I just attached three stack traces. However, only two of them are relevant for
this bug, but I am not knowledgeable enough to know which one is not.
Why do I say that? We have a non-trivial sitemap, with 5 match sections implied
in this situation.
Called URL is: /corresponsales/propuestas/deportes/inicio.html
"External" sitemap part gets called:
<!-- Step 1 -->
<map:match pattern="**.html">
<map:act type="session">
<map:parameter name="action" value="create"/>
<map:act type="session-propagator">
<map:parameter name="java:comp/env/skin" value="{&skin;}" />
<map:generate src="cocoon:/interno/{../../1}"/><!-- This calls Step
2 -->
<map:call resource="xpage2html">
<map:parameter name="hoja" value="pantalla"/>
<map:parameter name="pagina" value="{../../1}"/>
</map:call>
<map:serialize status-code="200" />
</map:act>
</map:act>
</map:match>
Here is the relevant part of the "internal" sitemap, which is mounted on
"/interno" and so its "Step 2" at the bottom is called from Step 1:
<!-- Step 5 -->
<map:match pattern="inclusion/**/lista-descendiente-*(*)">
<map:generate type="directory" src="{&paginas;}/{1}">
<map:parameter name="include" value=".*\.html|^[^.]*$"
/><!-- Directories that have no period and HTML files -->
<map:parameter name="exclude" value="historico" />
<map:parameter name="reverse" value="true" />
<map:parameter name="sort" value="{2}" />
<map:parameter name="depth" value="3" />
</map:generate>
<map:transform type="paginate" src="pagesheets/file6.xml"><!--
Gets the dir:file paged by groups of 6 -->
<map:parameter name="page" value="{3}" />
</map:transform>
<map:transform src="xsl/xdoc/directory.xsl">
<map:parameter name="path" value="{1}" />
<map:parameter name="orden" value="{2}" />
</map:transform>
<map:serialize/>
</map:match>
<!-- Step 4 -->
<map:match pattern="inclusion/**/lista-descendiente-*">
<map:redirect-to
uri="cocoon:/inclusion/{1}/lista-descendiente-{2}(1)" /><!-- Calls Step 5 -->
</map:match>
<!-- Step 3 -->
<map:match pattern="paginas/**">
<map:select type="resource-exists">
<map:when test="{&paginas;}/{1}.xdoc"><!-- This file
exists, so this is the one that gets called. See the file below -->
<map:generate src="{&paginas;}/{1}.xdoc"/>
</map:when>
<map:otherwise>
<map:generate type="html" src="{&paginas;}/{1}.html"/>
<map:transform src="xsl/xdoc/html.xsl"/>
</map:otherwise>
</map:select>
<map:transform type='xinclude' /><!-- This xincludes Step 4.
See the file below for URL -->
<map:serialize/>
</map:match>
<!-- Step 2 -->
<map:match pattern="**">
<map:aggregate element="page" >
<map:part label="contenido" src="cocoon:/paginas/{1}"/><!--
This will call Step 3, which will ultimately call directory generator, but
calling isValid() twice -->
<map:part src="cocoon:/datos/version-pdf/{1}" /><!-- This
uses directory generator, and isValid() only gets called once, so sitemap not
posted. One of the stack traces comes from here. -->
<map:part src="cocoon:/navegacion/principal"/>
<map:part src="cocoon:/navegacion/secundaria/{1}"/>
<map:part src="cocoon:/datos/calendario/hoy/completo"/>
<map:part src="{&dinamico;}/xml/buscadores.xml"/>
</map:aggregate>
<map:serialize/>
</map:match>
inicio.xdoc file contains (only relevant part shown):
<xdoc xmlns:xi="http://www.w3.org/2001/XInclude";>
<head>
<title>[...]</title>
</head>
<body>
[...]
<xi:include
href="cocoon://interno/inclusion/corresponsales/propuestas/deportes/lista-descendiente-lastModified"/><!--
Calls Step 4 -->
</body>
</xdoc>
I hope it is not too difficult to follow. :-(
> Generator "directory": Caching too much
> ---------------------------------------
>
> Key: COCOON-1681
> URL: http://issues.apache.org/jira/browse/COCOON-1681
> Project: Cocoon
> Type: Bug
> Components: * Cocoon Core
> Versions: 2.1.8, 2.1.7
> Reporter: Antonio Fiol
> Assignee: Jean-Baptiste Quenot
> Attachments: DirectoryGenerator.java.patch, stack1, stack2, stack3
>
> In some cases, an update to the directory is not detected by the
> DirectoryGenerator.
> Debugging the issue, I discovered that isValid() is called twice on the same
> DirValidity, but it returns different values (-1 the first time, 1 the second
> time).
> Apparently, the reason for the inconsistency would be solved by removing the
> first of the two lines that update the expiry time in the isValid() method in
> DirValidity, but I am not sure whether this could cause problems in other
> places.
> A possibility would be that a DirValidity stores the fact that it already
> detected it is invalid, and is changed so that it always return -1. But...
> Are DirValidity objects reused? Could this change cause problems? I have not
> tested, so I don't know.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
