Daniel Henrique Alves Lima wrote:
Yes !
Now imagine my frustration with ooffice escaping a ';' :-(
Browser, wget and other applications seems to work ok with URL encoded
jsessionid.
On Tue, 2009-06-30 at 00:00 +0200, André Warnier wrote:
Daniel Henrique Alves Lima wrote:
...
Hi.
If I understand what you are trying to do :
1) a client enters your application, authenticates, navigates, and
displays a result html page.
2) on this page, is a button that says "get this page as PDF"
3) the client clicks on that button, and is supposed to receive the same
page, but this time as a PDF.
4) At the server side, you want to use OOo to create the PDF version
from the html page
5) and OOo is capable, given a URL, to retrieve this page, and then
given appropriate commands, to return a PDF version of the page.
6) But OOo has trouble with the "jsessionid" part of the URL, although
it needs it in order to retrieve the page on behalf of the client.
Right ?
Ok then, let me suggest maybe another architecture, a bit different, but
where you might not have that problem.
I will just propose the general outline.
7) the PDF button on the page, points to the same URL as the one by
which the page was retrieved, plus an additional query parameter. For
example : "http://the original page URL...?p1=v1&p2=v2&....&fmt=PDF".
(You could even generate that on-the-fly using some javascript)
8) you create a servlet filter around your webapp.
This servlet filter, on the way in, picks up the additional parameter.
If it is not there, it does nothing and the request is processed as
usual, giving a html result page.
If the additional parameter is there, the filter sets a flag (for
example, request.setAttribute(x))
9) the request is processed as normally by your webapp, generating the
html response
10) on the way out, the filter intercepts the response. If the flag is
not set, it does nothing and lets the html response through.
If the flag is set, it does something totally different.
11) the filter captures the html output, and writes it to a local
temporary file. Then it calls OOo /on this file/, and asks for a PDF
version. Then it picks up the PDF version, and returns this as a
response, instead of the original.
(and deletes the temporary files).
This way, OOo never has to deal with a URL, and thus also not with the
jsessionid.
You may want to have a look at this :
http://code.google.com/p/jodconverter/
(I use that one in another context - not Tomcat - and it works fine)
You may also have a look at "htmldoc", as an alternative to OOo to
generate PDF from html.
Mmmmm. I'm thinking of a problem : if your pages contains links to
embedded objects (like images etc..).
In that case it may be better if your "PDF button" points to another
webapp, passing the original URL as a parameter. This webapp would use
wget to retrieve the original page and its embedded content, rewriting
the embedded URLs appropriately (it can do that), and then call OOo on
the html file.
One other issue bothers me a bit in all this : surely, you are not going
to load OOo for each request, just to process one response page.
So you will have to start OOo in server mode, and talk to it through
it's UNO interface. But how does it handle multiple concurrent requests ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
