tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Changing url rewriting behaviour (';jsessionid')
Date Mon, 29 Jun 2009 22:52:28 GMT
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 

You may want to have a look at this :
(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:
For additional commands, e-mail:

View raw message