This reminds me of something similar I ran into a while ago. I can't remember 
the details nor how I eventually got around this and/or whether you run into 
the same but the (weird) behavior you describe does look very similar.


Perhaps it helps


On 01 Sep 2010, at 17:53, Alexios Giotis wrote:

> Hello,
> The javadoc and the class name suggest that FopFactory should be thread-safe 
> although this is not explicitly written. If this is not thread-safe then 
> please ignore what follows.
> I am using FOP 1.0 to produce PDF documents concurrently from FOP 
> intermediate format. The PDF documents share a lot of common images, so I 
> decided to use a single instance of FopFactory to reduce memory requirements. 
> From the single FopFactory, I produce different instances for different 
> threads like this:
> FOUserAgent userAgent = fopFactory.newFOUserAgent();
> IFDocumentHandler targetHandler = 
> fopFactory.getRendererFactory().createDocumentHandler(userAgent,outputFormat);
> IFUtil.setupFonts(targetHandler);
> targetHandler.setResult(new StreamResult(outStream));
> IFConcatenator concatenator = new IFConcatenator(targetHandler, null);
> for (int i = 0; i < numberOfDocumentsToConcatenate; i++) {
>  Source src = new SAXSource(myOwnApplicationXmlFilters, new 
> InputSource(myOwnInputStream));
> concatenator.appendDocument(src);
> }
> The problem is that even on my 2-core laptop, I frequently get exceptions 
> silently written in standard error. Different stacktraces are attached and as 
> you can see happen when batik parses the SVG files. For the same input the 
> strings read are corrupted. For example the overflow="visible" is read as 
> "vssible" and then later as "vissibll". Also the fill="#EC2227" is try to 
> parse "E7E8" as color.
> The workaround for my application is to have a new instance of FopFactory per 
> thread but I would like to fix it and create a patch. Since I am quite new to 
> FOP, I would like some advise on what should be the proper level. The higher 
> one would be the FopFactory (but it's too high and I could do it externally 
> in my code), then there is the 
> org.apache.xmlgraphics.image.loader.ImageManager and at the end we get to the 
> very low level org.apache.batik.css.engine.CSSEngine or 
> org.apache.batik.css.parser.Parser.
> Secondly, I think it's not a good practice that the exceptions are written in 
> STDERR instead of propagating to the application. What do you think ?
> This is my first post to fop-dev and hopefully this is the proper one.
> Thanks,
> Alexis
> <stacktraces.txt>

Reply via email to