--- Comment #12 from Jeremias Maerki <[EMAIL PROTECTED]> 2008-10-21 05:12:39
(In reply to comment #11)
> (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),
Hint: XSLT parameters
> 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'd simply determine a unique ID for each report instance (something simple as
a counter) and pass that in as an XSLT parameter. The stylesheet can then
append that to the URI: file:myimage.png?id=12345,
> I wonder, how I can get FOP working to process multiple documents in multiple
That's what I was thinking, too. You're not going to be happy when you always
write the same file. IMO that's a really bad idea. The trick with the different
directories is not a bad idea if you actually have to write the image to a file
in the first place.
> 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 http://xmlgraphics.apache.org/fop/0.94/embedding.html#multithreading
> ("Apache FOP may currently not be completely thread safe.") is not very
That's just to cover our collective asses. FOP is thread-safe (if no little bug
has sneaked in somewhere due to some oversight, multi-threading testing is not
part of our normal test suite). But that doesn't mean it's not a good idea to
do careful multi-threading testing of your application as a whole.
I'm afraid I can't give you the best idea with the information I currently
have. I don't know how you create your image. I assume you generate it before
you call FOP. Assuming you have some information that lets you identify the
data that needs to be turned into an image, consider passing that information
 into the XSLT stylesheet as a XSLT parameter (similar to what I suggested
above) but this time, you use this information to build up a private URI that
holds all information to uniquely identify the image belonging to that report.
Then, write a URIResolver that can deal with this private URI scheme to
generate the image on the fly. That might actually allow you to bypass writing
the image to a file, thus making the whole thing faster.
 I'll try to show this by example: Assuming you can gather all your data
from your database (assuming you use one) you could pass in the ID of the main
record. my:report?id=873468&color=red could then be your unique URI for the
report 873468 and some data shall be highlighted in red (random example
feature). Your URIResolver will listen to the "my" scheme and parse it, then
return an InputStream (or for example a DOM (DOMSource) in case of SVG) that
accesses the finished image.
Maybe that helps.
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.