Hi Peter,

Thanks for pointing this out. It differs in that the instance of FOUserAgent was shared, but other than this, it's exactly the same case. Finally, this leads to https://issues.apache.org/bugzilla/show_bug.cgi?id=46360

which is still open.

As I read from the thread, this is a complex case and in batik they have good reasons not to be thread-safe.

Finally, sorry for my other posting with the same title. I though that only the subscribed email address can post.


On 1-9-10 11:30 PM, Peter Coppens wrote:

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:


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 = 
targetHandler.setResult(new StreamResult(outStream));
IFConcatenator concatenator = new IFConcatenator(targetHandler, null);
for (int i = 0; i<  numberOfDocumentsToConcatenate; i++) {
  Source src = new SAXSource(myOwnApplicationXmlFilters, new 

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.



Reply via email to