I've created a Stripes ActionBean to stream dynamically generated images to the response. I'm using this component for a HTML page that I'm going to convert to PDF through xhtmlrenderer. However, when I try to generate the PDF, the images don't show up. On the dynamically created HTML page, they're ok but not on the PDF.
To create the image, I use BufferedImage, and JPEGImageEncoder.
During the XHTML->PDF step, is the image generator URL being called at all?
Joined: Dec 02, 2010
I'm not sure. Here's how I do the conversion:
1) generate the formatted page to a certain URL
2) use a client internally (Apache HTTPClient) to fetch the document from that URL
3) create a Document object (w3c) from the fetched entity
4) use xhtmlrender to convert the Document object to PDF
It might not be the best way to go about it but that's how I did it. So essentially I format everything through one actionBean and convert it to PDF on another. So, I'm not sure how xhtmlrender go about rendering the images but as I've said, the "static" images get shown properly.
Joined: Oct 14, 2008
What do you mean by "static" images - how does their URL differ from those of the "dynamic" image?
I'd add some logging to your image generation ActionBean - I'll bet it isn't called at all during the PDF generation. You might also do some HTTP monitoring to see at which times requests for which URLs go out, and what the responses are.
Joined: Dec 02, 2010
By "static images" I meant they're already in the deployment as images and that they're not created through code. The URLs for static and dynamically created images don't differ that much. I created the image generator ActionBean so that its URL is like pointing to a "static" image.
As for the generator being called on conversion, I found out--thanks to Lester's suggestion--that it's NOT being called. The thing is: there's an interceptor in the application that limits access to ActionBeans to logged in users and the HTTPClient is not set to be logged in.
I could probably work with a solution from here. Thanks.
EDIT: it probably isn't the HTTPClient that's not set to be logged in exactly but some other internal component/s.