https://issues.apache.org/bugzilla/show_bug.cgi?id=46048
--- Comment #12 from Jeremias Maerki <[EMAIL PROTECTED]> 2008-10-21 05:12:39 PST --- (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, file:myimage.png?id=12346.... > I wonder, how I can get FOP working to process multiple documents in multiple > threads. 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 > encouraging. 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 [1] 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. [1] 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.
