It might be worth switching to Saxon's AntTransform task (or even, if it's
not performance critical, invoking Saxon via an exec task).
If I remember rightly, the Ant xslt task reuses the same JAXP Transformer
for doing multiple transformations, without resetting it. This means that
the document pool, and information about which URIs have been read and
written, is potentially retained across a sequence of transformations rather
than just one.
The error message occurs when document() or doc() is used to read a file,
and the absolutized URI (determined by Saxon, not by the URIResolver) is
present in the table Transformer.allOutputDestinations. URIs are added to
this table as follows:
(a) the URI of the principal output of the transformation
(b) a URI written using xsl:result-document
(c) a document read using doc() or document() (but that shouldn't cause the
error, because if the document has already been read, the doc() function
will not be performing this check).
URIs are removed from the table when saxon:discard-document() is called. The
entire table is cleared when Transformer.reset() is called, but as
mentioned, I'm not convinced that Ant is calling this.
You could try calling saxon:discard-document() on the offending URI.
> -----Original Message-----
> From: Deborah Pickett [mailto:debbiep-list-saxon@...]
> Sent: 14 August 2009 04:58
> To: saxon-help@...
> Subject: [saxon] Cannot read a document that was written
> during the same transformation
> Wait! It's not what you think. I'm not trying to write a
> file and then read it.
> The tech writers that I support got the "Cannot read a
> document that was written during the same transformation"
> error while running Saxon-B 188.8.131.52j inside a help build.
> It's a heisenbug; not every build reports it, and when it
> happens, it isn't even on the same source file. Saxon is
> being called from inside an Ant <xslt> task on a fileset.
> The weird bit is that the stylesheet
> which imports
> is pure XSLT 1.0, so there's no chance that we were using
> <xsl:result-document>. The error was reported in line 66 of
> the latter file, which is just a <xsl:variable> that doesn't
> use document() (though I'm aware of Saxon's lazy evaluation
> policy so I will take that line number with some salt).
> The only thing that has changed recently is an increase in
> network flakiness (the stylesheets are on a network share),
> but I'm having a hard time attributing this error message to
> that cause.
> Let Crystal Reports handle the reporting - Free Crystal
> Reports 2008 30-Day trial. Simplify your report design,
> integration and deployment - and focus on what you do best,
> core application coding. Discover what's new with Crystal
> Reports now. http://p.sf.net/sfu/bobj-july
> saxon-help mailing list archived at
> http://saxon.markmail.org/ saxon-help@...