--- Comment #11 from M.H. <[EMAIL PROTECTED]>  2008-10-21 04:48:06 PST ---
(In reply to comment #10)
> The URIResolvers are completely irrelevant for image caching, they
> just provide access to the actual resource when given a URI.

Thanks for this clearing up! Now I can  stop playing around with the
URIResolver in hope to get it somehow fixed.

Then I don't understand your comment #3: as I can't write a unique path to the
XSL (as the XSL never changes because it is the layout of the report), we use
relative paths (as they worked with FOP 0.20.5 Java API flawlessly). These
relative paths result in the very same image file name for the same report but
other data. The only workaround I see here, is to make an additional XML
transformation of the XSL to find such relative paths and replace them with
temporary full paths, which is not very elegant.

I wonder, how I can get FOP working to process multiple documents in multiple
threads. I guess, the only promising approach so far (FOP 0.95) is, to use new
FopFactories and UserAgents for each thread and each report generated. But the
note in
("Apache FOP may currently not be completely thread safe.") is not very

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to