Re: Caching ancillary file content

2004-06-04 Thread Joerg Heinicke
On 03.06.2004 14:55, Peter Flynn wrote:
In my XSLT I extract values from some ancillary files using 
the document('foo.xml') function. This works fine, but when 
the foo.xml file is changed (eg by some external agency like a timed
script), its old content continues to be served by 
Cocoon. Eventually it starts to serve the new content (but 
I haven't been able to time it so I don't know what the lag 
is). 

The archives have many comments on caching, but they appear
to refer mostly to custom apps, JSP routines, etc, none of
which seem apply to this situation, which is an XML document
being transformed to HTML by an XSLT script. I've trawled 
the docs for caching, but it only mentions the caching of
the primary content (the src value of map:generate), not any
additional files opened from within the XSLT.

Ideally I'd like all caching of secondary content to be 
turned off permanently, so that Cocoon would physically open every file
that the XSLT expects to use, every  time the  primary content is
served, and not cache anything from 
previous hits. This is a low-volume app, so I am prepared 
to suffer any I/O penalty in doing so.

Is this possible? I'm running jakarta-tomcat-4.1.18 with
cocoon 2.0.4 under j2sdk1.4.1_01 on RH9. I'll upgrade if
necessary, but the machine will eventually be wiped and
reinstalled with RHE, which will mean a new version of
everything, so if this caching is a bug, I'm interested in 
a short-term fix :-)
http://issues.apache.org/bugzilla/show_bug.cgi?id=10203
From the bug date you will also see, that there will probably be no 
short-term fix.

Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Caching ancillary file content

2004-06-04 Thread Peter Flynn
On Fri, 2004-06-04 at 12:02, Joerg Heinicke wrote:
 On 03.06.2004 14:55, Peter Flynn wrote:
[caching]
 http://issues.apache.org/bugzilla/show_bug.cgi?id=10203
 
 From the bug date you will also see, that there will probably be no 
 short-term fix.

That's actually the reverse of this problem: the OP seems
to be complaining that ancillary data retrieved from a call
to the document() function is *not* being cached, whereas
in fact it *is* (and shouldn't be) -- and the waters were
muddied by the problem being confused with the behaviour of
xsl:include.

Not important now: I coded around it. But it would be a big
benefit to the behaviour of Cocoon if this was fixed: it is
*not*, as Carsten suggests, a feature request: it's a bug.

If I write 

   xsl:value-of select=document('foo.xml')/bar/@blort/

and it emits the string xyz because foo.xml contains

   bar blort=xyz/

and then an external system changes foo.xml so that it now
contains

   bar blort=abc/

and I reload the URI of the pipeline in my browser, I still
get xyz because the content of the file was cached. 

Whatever code in Cocoon that is performing this caching
simply needs to be removed.

///Peter



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Caching ancillary file content

2004-06-04 Thread Joerg Heinicke
On 04.06.2004 18:06, Peter Flynn wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=10203
That's actually the reverse of this problem: the OP seems
to be complaining that ancillary data retrieved from a call
to the document() function is *not* being cached, whereas
in fact it *is* (and shouldn't be) -- and the waters were
muddied by the problem being confused with the behaviour of
xsl:include.
No, it matches exactly your problem. The summary is Docs referenced by 
XSLT's document() are not included in cache validity. This means the 
cache validity calculation of the transformation is not based on 
external documents, so changes in a document accessed via document() are 
not recognized and the cache is seen as valid.

Not important now: I coded around it. But it would be a big
benefit to the behaviour of Cocoon if this was fixed: it is
*not*, as Carsten suggests, a feature request: it's a bug.
You are free to add your comment to the bug and maybe also vote for it.
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]