It seems that Batik is not thread save. We have several fixed/static SVGs that we include in XSL-FO and transform via Apache FOP. As long as we create the reports sequentially, such errors (see below) never occured so far. But when 2 reports are generated concurrently and both have (the same) SVG files included, a NullPointerException can occur: --------------------------------------------------------------------------- 084942921 SEVERE T61: SVG Errorfile:/C:/Programme/ddf/xml/images/V10271.svg: The attribute "style" represents an invalid CSS declaration ("fill:#ef7b00; fill-rule:nonzero; stroke:none; stroke-width:1; stroke-linecap:butt; stroke-linejoin:miter; stroke-dasharray:none;"). Original message: java.lang.NullPointerException org.w3c.dom.DOMException: file:/C:/Programme/ddf/xml/images/V10271.svg: The attribute "style" represents an invalid CSS declaration ("fill:#ef7b00; fill-rule:nonzero; stroke:none; stroke-width:1; stroke-linecap:butt; stroke-linejoin:miter; stroke-dasharray:none;"). Original message: java.lang.NullPointerException at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown Source) at org.apache.batik.css.engine.CSSEngine.getComputedStyle(Unknown Source) at org.apache.batik.bridge.CSSUtilities.getComputedStyle(Unknown Source) at org.apache.batik.bridge.CSSUtilities.convertDisplay(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) at org.apache.batik.bridge.GVTBuilder.build(Unknown Source) at org.apache.fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:188) at org.apache.fop.render.AbstractGenericSVGHandler.handleXML(AbstractGenericSVGHandler.java:57) at org.apache.fop.render.AbstractRenderer.renderXML(AbstractRenderer.java:808) at org.apache.fop.render.PrintRenderer.renderDocument(PrintRenderer.java:169) at org.apache.fop.render.pdf.PDFImageHandlerXML.generateImage(PDFImageHandlerXML.java:55) at org.apache.fop.render.pdf.PDFRenderer.putImage(PDFRenderer.java:1745) at org.apache.fop.render.pdf.PDFRenderer.renderImage(PDFRenderer.java:1679) at org.apache.fop.render.AbstractRenderer.renderViewport(AbstractRenderer.java:743) at org.apache.fop.render.AbstractPathOrientedRenderer.renderViewport(AbstractPathOrientedRenderer.java:621) at org.apache.fop.render.AbstractRenderer.renderInlineArea(AbstractRenderer.java:626) at org.apache.fop.render.pdf.PDFRenderer.renderInlineArea(PDFRenderer.java:1345) at org.apache.fop.render.AbstractRenderer.renderLineArea(AbstractRenderer.java:601) at org.apache.fop.render.pdf.PDFRenderer.renderLineArea(PDFRenderer.java:1336) at org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:536) at org.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:573) at org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329) at org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:526) at org.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:573) at org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329) at org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:526) at org.apache.fop.render.AbstractPathOrientedRenderer.renderReferenceArea(AbstractPathOrientedRenderer.java:548) at org.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:560) at org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329) at org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:526) at org.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:573) at org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1329) at org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:526) at org.apache.fop.render.AbstractRenderer.renderRegion(AbstractRenderer.java:322) at org.apache.fop.render.AbstractRenderer.renderRegionViewport(AbstractRenderer.java:284) at org.apache.fop.render.AbstractRenderer.renderPageAreas(AbstractRenderer.java:247) at org.apache.fop.render.AbstractRenderer.renderPage(AbstractRenderer.java:229) at org.apache.fop.render.pdf.PDFRenderer.renderPage(PDFRenderer.java:801) at org.apache.fop.area.RenderPagesModel.addPage(RenderPagesModel.java:113) at org.apache.fop.layoutmgr.AbstractPageSequenceLayoutManager.finishPage(AbstractPageSequenceLayoutManager.java:312) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.finishPage(PageSequenceLayoutManager.java:167) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:108) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:234) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:123) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:340) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:169) at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1101) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at de.ddf.xml.FOP.fo2PDF(Unknown Source) at java.lang.Thread.run(Unknown Source) --------------------------------------------------------------------- The result is, that the SVG image on one the report is displayed but with strange/different colors.
A similar bug has already been discussed (and fixed in FOP Trunk) in #46360 (https://issues.apache.org/bugzilla/show_bug.cgi?id=46360). Yes, Batik is not thread-safe if you operate off the same DOM and that's what was FOP's problem. Unless your bug still occurs with FOP Trunk I'm inclined to close this bug here as "WONTFIX" after Thomas DeWeese explained why we need to clone the DOM in FOP.
"... if you operate off the same DOM ...". Well, in our case these are 2 separate threads holding their own XML and XSL-FO documents (but referencing the same fixed SVG (as it is a logo)). So I would answer: no, it's not the same DOM ...?
(In reply to comment #2) > "... if you operate off the same DOM ...". Well, in our case these are 2 > separate threads holding their own XML and XSL-FO documents (but referencing > the same fixed SVG (as it is a logo)). So I would answer: no, it's not the same > DOM ...? > But you do know that FOP has an image cache that reuses images from the same location for performance reasons? Yes, it's the same DOM if you reference the same fixed SVG. That's why I asked you to retest with FOP Trunk.