Open GoogleCodeExporter opened 8 years ago
Hi,
Any one looked at this issue? Can any one provide usefulinformation to fix this
issue?
Original comment by ampau...@gmail.com
on 23 Mar 2011 at 5:08
Sorry...missed this post!
>>I tried setting the actual IP Address of the URL worked fine.
Sounds like you have dug completely into the problem and have something
working. I would not have any more insight into the problem...
I know this is a poor response, but you could use the PDFP export. That just
uses iText directly.
Original comment by jeff.johnston.mn@gmail.com
on 23 Mar 2011 at 3:42
Thanks for the reply. I feel lucky if you can look at this issue, client does
not agree for the solution which I used IP address, because in a clustering
environment we ca not guaranty to a particular IP address becuase request may
go to any node. We use Apache and the request will be routed to Weblogic. It
seems it is a bug in Flying saucer API. If you can look at this issue that
would be helpful.
Thanks,
Moses Paul A
Original comment by ampau...@gmail.com
on 23 Mar 2011 at 4:31
I wouldn't have any idea where to start...you would have to fix this yourself,
or switch to use the PDFP export.
Original comment by jeff.johnston.mn@gmail.com
on 23 Mar 2011 at 5:18
This is a problem I encountered several times. The flying saucer library
(xhtmlrenderer) has this bad habit of trying to retrieve the CSS for the PDF by
an URL connection. So this can produce many and funny different problems. I
already fixed 2 and maybe found a third one soon:
1) If the web application works with SSL, trying to get the css this way will
fail because the application MAY NOT TRUST ITSELF. Solution: The SSL
certificate (of Apache or Weblogic/Tomcat) has to be in the repository of the
Java VM that runs the app server (in its cacerts, for example). This way the
app can get files doing https requests to itself, trusting itself, crazy isn't?
2) If some kind of http authentication is set in Apache (via .htaccess or
httpd.conf) the app MAY NOT be able to retrieve the CSS by an URLconnection.
Solution: I can't remember right now cause I don't have the code at this moment
but it's some java instruction to tell the app to use http authentication in
any URLConnection, if needed, with the user and password set in Apache
I hope this helps people having this problem in Jmesa or with xhtmlrenderer.
Cheers,
Alex
Original comment by AlejaV...@gmail.com
on 19 Jul 2011 at 8:13
Thanks for the tips!
I posted this in the export recipes section on the wiki.
http://code.google.com/p/jmesa/wiki/ExportRecipes
Original comment by jeff.johnston.mn@gmail.com
on 20 Jul 2011 at 2:36
More info in case 2) and a new case 3):
2) If some kind of http authentication is set in Apache (via .htaccess or
httpd.conf) the app MAY NOT be able to retrieve the CSS by an URLconnection.
Solution: Instruction to tell the app to use http authentication in any
URLConnection, if needed, with the user and password set in Apache. (execute it
asap)
java.net.Authenticator.setDefault(new BasicHTTPAuthenticator("user",
"password"));
3) The url that xhtmlrenderer will try to use will be exactly the same as the
user browsing the web app (that causes the https problem) and can produce
another problem, when the server machine MAY NOT BE ABLE to REACH ITSELF. If
using localhost or a lan ip won't be a problem, but when using an INTERNET IP
(when the server goes online, production envorioment) the server may not be
able to connect in a loop using its internet ip. This is caused by the ISP
routers, that can't make a request to its own external internet ip.
Solution: The server HAS TO HAVE A DOMAIN NAME in the internet. And that name
has to be in the server's "hosts" file directing that name to localhost.
Example:
Server in internet with ip: 80.80.80.80
App will try to get css from: 80.80.80.80/myapp/route_to_css/pdf.css , and MAY
FAIL
App server should have a name (in internet) like: my_amazing_app.com/myapp
App server needs this in hosts file (/etc/hosts): 127.0.0.1 my_amazing_app.com
This way the server will resolve our fancy internet name to localhost and be
able to reach itself not trying to make a roundtrip travel around internet...
Original comment by AlejaV...@gmail.com
on 26 Jul 2011 at 6:56
Original issue reported on code.google.com by
ampau...@gmail.com
on 21 Mar 2011 at 10:17