Hi,
an internal project of ours uses Xalan to parse and convert XML files to
reports in PDF format. We are having some trouble getting Xalan to do
what we want, so I'd like to solicit advice.
First, some background (sorry for so much text, I tried to make it brief):
The reports we produce have some very peculiar rules for pagination
(placing of page breaks): Sometimes certain pairs of pages need to face
each other, so empty pages must be inserted according to special rules,
and sometimes paragraphs must be reordered to achieve this.
Therefore, use custom Java code that "plugs into" Xalan (by using a
special XSL file that calls into our classes). This code implements
custom pagination rules.
Our problem when implementing this was that we found no direct support
in XSL / Xalan to *reorder* parts of the document (so the order in the
final PDF differs from the order in the XML input file). So we
implemented a PageBreaker class (called by pagebreaker.xsl), which
maintains an internal queue of document fragments. In practice the
pagebreaker.xsl contains templates:
* start-part: Starts a new queue (called "part")
* write-unit: puts an XML fragment (usually a paragraph) into the
internal "queue"
* finish-part: Writes out the accumulated queue, reordering as needed.
These templates can be used from an XSL file to produce reports with the
special pagination.
Internally, this queuing of document fragments is implemented (in
write-unit) by having setter methods in our code that accept an
org.w3c.dom.NodeList. When this code is used, Xalan passes in a document
fragment as a NodeList. The NodeList is queued internally, document
processing continues without producing output, and then later when
"finish-part" is called, the whole (reordered) queue is retrieved and
returned to Xalan for rendering.
*Our problem:*
Sometimes, when we retrieve the NodeList instances (more precisely, the
org.w3c.dom.Node instances inside), their contents have unexplicably
changed. It's as if someone changed the queued instances behind our back
between the time we put it in and the time we take it back out of the queue.
After some digging through Xalan I found out that the NodeList and Node
instances returned by Xalan are just facades for Xalan's internal data
structures. Apparently the actual document data is stored in internal
lists inside Xalan, and the Node instances just point there.
We found out that uncommenting the line
xctxt.popRTFContext();
in org.apache.xalan.templates.ElemTemplate.execute(TransformerImpl)
made our problems go away.
We believe that popRTFContext() does some internal clean-up which
invalidates the data we queue.
My question:
Can anyone explain more about the internal workings of Xalan?
Is our analysis correct?
Are there any problems with disabling the above line?
Are there any other pitfalls to be expected, or can we just continue
working without popRTFContext()?
Greetings,
Sebastian Leske
P.S. Sorry for not posting actual code. It's proprietary, and also a
rather huge package, and I'm not sure how to simplify it, as the problem
only occurs with large documents.
I'll try to answer any specific questions by looking into the original code.
--
Sebastian Leske
System- und Anwendungsentwicklung
Tel: 0211/92495-146
IOn AG
http://www.ion.ag/
Vorstand: Rudolf Franke, Erik Rehrmann, Manfred Siller
Aufsichtsratsvorsitzender: Reinhard Möntmann
Sitz der Gesellschaft: Erkrath
Amtsgericht Wuppertal: HRB 14181
USt Id-Nr.: DE 121642062
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscr...@xml.apache.org
For additional commands, e-mail: xalan-dev-h...@xml.apache.org
