cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <j3322...@yahoo.de>
Subject Re: Saxon as the default XSLT procesor
Date Sat, 03 Jan 2004 16:48:20 GMT
Nicola Ken Barozzi wrote:
>> document() calls in the style sheet,
> 
> There are. I'm gonna remove them soon, nut for now they are there, and 
> will the possibility to use them will remain some time for backward compat.
> 
>> because at least in the Cocoon releases I used it gets passed
>> null as Source quite often for no obvious reason.
> 
> Wierd...
> 
I think it's a Cocoon bug. The first invocation of the pipeline is ok,
but in followup incovations the XSLT processor often gets a null
SourceResolver (not Source, sorry). Xalan uses its own URIResolver in
this case, while Saxon (6.x series) takes it literally. That's one
of the dark corners of the TrAX spec, I couldn't find any regulations
guiding the behaviour.
The null is not a MT problem, it happens even for low load. I think
it has something to do with incorrect re-initialization of the pipeline
after the SourceResolver has been recycled and the reference had been
nulled.

Given the added problem that document() referenced stuff doesn't influence
cache validity, I switched to aggregation. If the document() gets the
URI from source XML, this can be painful (XSLT to an XInclude source,
then Xinclude, the the final XSLT instead of just one XSLT). The worst
thing is that you can't easily test the XSLT any longer with command
line tools, even though none of the dynamic features (like cocoon: URIS)
are used. If you've to ftp the damn sources to the app server, this really
slows down development :-/ .

J.Pietschmann

Mime
View raw message