My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 309: Not able to perform the PDF export
3 people starred this issue and may be notified of changes. Back to list
Status:  New
Owner:  ----


Sign in to add a comment
 
Reported by ampau...@gmail.com, Mar 21, 2011
What steps will reproduce the problem?
1. We have used PDF view by setting the css location.
2. We tried to export PDF worked fine in local environment but when we access the same URL from another location and tried the PDF gave the below error
3. Not able to perform the PDF export.
org.xhtmlrenderer.util.XRRuntimeException: IOException on parsing style seet from a Reader; don't know the URI.

We are using the below environment.
Jmesa 3.0.3, Linux, Weblogic App server,Apache Webserver.

We have overriden the code in  PdfViewExporter.java where we set teh BaseURL. I tried setting the actual IP Address of the URL worked fine. Flyin Saucer is not able to understand the general apache URLs. Please suggest. We need this bug to be fixed very urgent.

Comlete Error Log:

org.xhtmlrenderer.util.XRRuntimeException: IOException on parsing style seet from a Reader; don't know the URI.
	at org.xhtmlrenderer.context.StylesheetFactoryImpl.parse(StylesheetFactoryImpl.java:83)
	at org.xhtmlrenderer.context.StylesheetFactoryImpl.parse(StylesheetFactoryImpl.java:97)
	at org.xhtmlrenderer.context.StylesheetFactoryImpl.getStylesheet(StylesheetFactoryImpl.java:194)
	at org.xhtmlrenderer.context.StyleReference.readAndParseAll(StyleReference.java:123)
	at org.xhtmlrenderer.context.StyleReference.setDocumentContext(StyleReference.java:107)
	at org.xhtmlrenderer.pdf.ITextRenderer.setDocument(ITextRenderer.java:136)
	at org.xhtmlrenderer.pdf.ITextRenderer.setDocument(ITextRenderer.java:110)
	at org.jmesa.view.pdf.PdfViewExporter.export(PdfViewExporter.java:92)
	at org.jmesa.facade.TableFacade.renderExport(TableFacade.java:874)
	at org.jmesa.facade.TableFacade.render(TableFacade.java:852)



Mar 22, 2011
#1 ampau...@gmail.com
Hi,

Any one looked at this issue? Can any one provide usefulinformation to fix this issue?
Mar 23, 2011
Project Member #2 jeff.johnston.mn@gmail.com
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.

Mar 23, 2011
#3 ampau...@gmail.com
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
Mar 23, 2011
Project Member #4 jeff.johnston.mn@gmail.com
I wouldn't have any idea where to start...you would have to fix this yourself, or switch to use the PDFP export.
Jul 19, 2011
#5 AlejaV...@gmail.com
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
Jul 19, 2011
Project Member #6 jeff.johnston.mn@gmail.com
Thanks for the tips!

I posted this in the export recipes section on the wiki.

https://code.google.com/p/jmesa/wiki/ExportRecipes
Jul 25, 2011
#7 AlejaV...@gmail.com
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...

Sign in to add a comment

Powered by Google Project Hosting