Here's an update, and a potential bug.  The NPE was actually resulting from
an improper transformation of the XML.  The Element object passed in by
Apache SOAP needs to "promoted" to Document object status prior to being
passes to the transform in a DOMSource object.  This is accomplished with
the follow:

    Transformer transformer = tFactory.newTransformer( new StreamSource(
xsl_url ) );

    DocumentBuilderFactory dBuilderFactory =
    DocumentBuilder docBuilder = dBuilderFactory.newDocumentBuilder();
    Document doc = docBuilder.newDocument();
    Node newNode = doc.importNode( element, true );
    doc.appendChild( newNode );

    transformer.transform( new DOMSource( doc ), new SAXResult(
driver.getContentHandler() ));

    This produces a nice PDF.  I notice that by doing this, I do not have to
call the run() method, so therefore I'm assuming that this saves a step in
the entire rendering process.  Please correct me if I'm wrong, but am I to
believe that the PDF is being rendered as the SAX events are being fired by
the transformer?  By this, it seems like this should save me alot of memory
usage because I won't have to hold the XSL:FO output in an object.

    I am very happy with the way this is turning out.  I promise an article
on it as soon as I'm finished.y


David B. Bitton

Code Made Fresh DailyT
----- Original Message -----
From: "Jeremias Maerki" <[EMAIL PROTECTED]>
Sent: Friday, March 22, 2002 10:49 AM
Subject: Fw: Re: Rendering from a Document

> <comment>Oops, that one didn't make it to the list at first.</comment>
> DOM (Document) should work. But using DOM to process a 400MB XML? You
> wouldn't want to do that. Try to find a way to use SAX. You can fill SAX
> events into FOP to create the FO tree. Maybe it helps us to provide you
> with some pointers and ideas if you tell us what exactly you're trying
> to do.
> > I'm sorry to post this again but I need help.  Does passing a Document
datatype to the Driver
> > render() method work?  I have to potential to move XML files in excess
of 400MB and so I need to avoid as
> > moving of data in memory as possible.
> Cheers,
> Jeremias Märki
> Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
> Tel. +41 41 317 2020 - Fax +41 41 317 2029
> Internet
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

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

Reply via email to