Re: Bug when integrating with SAX?
The call to run() is not necessary. The transformation is started when the SAX startDocument() is called by the XSLT Transformer. On 22.11.2002 13:33:23 Matthias Brunner wrote: Hello, I am trying to use FOP by firing SAX events: fopDriver.setOutputStream(System.out); fopDriver.setRenderer(fopDriver.RENDER_XML); stylesheet.newTransformer().transform( new DOMSource(source), new SAXResult(fopDriver.getContentHandler()) ); fopDriver.run(); I get a NullPointerException when the formatting object tree is built. Am I doing anything wrong? Setting a logger does not help. When using the DefaultContentHandler instead of FOP's no error is reported. That's why I think it's a FOP bug. Software: FOP 0.20.4, Sun JDK 1.4.1_01, Linux Output: [ERROR] Logger not set [INFO] building formatting object tree [WARNING] Screen logger not set. [INFO] [1] [INFO] [2] javax.xml.transform.TransformerException: java.lang.NullPointerException at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1226) Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug when integrating with SAX?
Mmm, probably, I think I remember some saying that Crimson doesn't work correctly. Namespace issues probably. Not sure. On 22.11.2002 14:19:50 Matthias Brunner wrote: On Friday 22 November 2002 13:39, Jeremias Maerki wrote: The call to run() is not necessary. The transformation is started when the SAX startDocument() is called by the XSLT Transformer. This statement is not reached. The exception is thrown in the line before (to make sure I deleted it - no effects). Could it be that it is because I am using crimson rather than xerces? And an older xalan version (as deployed with jdk 1.4.1)? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug when integrating with SAX?
I believe this problem is due to the options not being set on the XML renderer or possible a particular option. It then gets an npe. The fix of course would be to set the options on the renderer, you can create the XMLRenderer yourself and set the options on it, then set the renderer on the driver. (2nd time today) Please only show the relevant part of the stack trace. java.lang.NullPointerException at org.apache.fop.render.xml.XMLRenderer.isCoarseXml(Unknown Source) at org.apache.fop.render.xml.XMLRenderer.renderDisplaySpace(Unknown Source) at org.apache.fop.layout.DisplaySpace.render(Unknown Source) at - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug when integrating with SAX?
On Friday 22 November 2002 14:26, Jeremias Maerki wrote: Mmm, probably, I think I remember some saying that Crimson doesn't work correctly. Namespace issues probably. Not sure. I tried it on the command line, with classpath und java endorsed dirs set. Does not help. BTW: Sorry for mailing 3 times. The mail server turned mad and I thought the first two lost. -- Matthias Brunner [EMAIL PROTECTED] PGP FP 7862 32B3 3B75 292A F76F 5042 8587 21AB 5B89 D501 Check out http://blumenstrasse.vol.at/~mb/gpgkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug when integrating with SAX?
Keiron, On Friday 22 November 2002 14:31, Keiron Liddle wrote: The fix of course would be to set the options on the renderer, you can create the XMLRenderer yourself and set the options on it, then set the renderer on the driver. thanks for this reply. I found the error. Will post a bug report in a minute. You have to do the following: XMLRenderer r = new XMLRenderer(); Hashtable opts = new Hashtable(); opts.put(fineDetail, new Boolean(true)); r.setOptions(opts); fopDriver.setOutputStream(System.out); fopDriver.setRenderer(r); stylesheet.newTransformer().transform( new DOMSource(source), new SAXResult(fopDriver.getContentHandler()) ); (2nd time today) Please only show the relevant part of the stack trace. IMHO it is sometimes very hard to determine which part of the stack trace is relevant, at least for non-developers. I think that error reports can hardly have too much context information, especially since these stacktraces are not really megabytes in size. Kind regards! -- Matthias Brunner [EMAIL PROTECTED] PGP FP 7862 32B3 3B75 292A F76F 5042 8587 21AB 5B89 D501 Check out http://blumenstrasse.vol.at/~mb/gpgkey.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]