Not able to perform the PDF export

[GoogleCodeExporter]

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)

Original issue reported on code.google.com by ampau...@gmail.com on 21 Mar 2011 at 10:17

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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