My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 55: Export to PDF does not work
2 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  ----
Closed:  Nov 2007


 
Reported by dirk.mic...@googlemail.com, Nov 13, 2007
I added the export option TableFacadeImpl.PDF to the
BasicPresidentController example. Line 62 reads now:

tableFacade.setExportTypes(response, CSV, EXCEL, PDF);

I also added the needed libraries from the export-dependencies package and
flyingsaucer.

When I klick on the PDF export link I get a ServletException "Operation
timed out: connect:could be due to invalid address" (whole stacktrace is
appended as a file)

I tried the versions 2.2.4 and 2.3_07.10.29.

Could you please fix this bug because I really need this functionality.

thanks.
Dirk Michaelsen
stacktrace.txt
4.6 KB   View   Download
Nov 13, 2007
#1 extremec...@gmail.com
Could you try saving the file to disk as a test? Try the section...."My exports are
not readable. What is wrong?"

https://code.google.com/p/jmesa/wiki/FAQ

The build you should be using is 2.2.4.

Nov 13, 2007
#2 dirk.mic...@googlemail.com
The saved file is added as attachment.
output.pdf
7.4 KB   View   Download
Nov 13, 2007
#3 extremec...@gmail.com
Are you saying that you followed the FAQ instructions and this is the output? If so
then I see that the output is not valid...do you get any error messages while
exporting it to just this file?
Status: Accepted
Nov 13, 2007
#4 dirk.mic...@googlemail.com
Yes I followed the FAQ instructions and there was no error message.
Nov 13, 2007
#6 extremec...@gmail.com
My fault...that was not a valid test. The getBytes() method only returns the String
bytes. In fact if I rename your output.pdf file to output.html it displays your table
in my browser.

The actual conversion to a pdf file happens in the exporter for this view:
http://jmesa.googlecode.com/svn/trunk/jmesa/src/org/jmesa/view/pdf/PdfViewExporter.java

Take a look at the export method and rip out the code to do the rendering and then
output that to a local file. If that is confusing I could try it tonight myself. What
I am trying to do is see if we are able to get a valid pdf file outside of the
servlet container context. I really think what we are going to find is that the pdf
is being generated, but then one of your filters is causing problems when exported
because of a container issue. After doing this for some time now I have found that
usually the filters are the cause. There are workarounds but I am hoping that we can
prove it is or is not a valid pdf file first.

Nov 13, 2007
#7 extremec...@gmail.com
Here, try putting this in your class to debug it. This will tell us if the pdf is
able to be created...

I am going to come up with a export utility class too so that developers can test
their exports like this.


    private void testPdfOutput(HttpServletRequest request, TableFacade tableFacade) {
        
        Limit limit = tableFacade.getLimit();
        if (!limit.isExportable() || !limit.getExport().getType().equals("pdf")) {
            return;
        }
        
        View view = tableFacade.getView();
        byte[] contents = view.getBytes();
        
        System.setProperty("xr.load.xml-reader", "org.ccil.cowan.tagsoup.Parser");
        System.setProperty("xr.util-logging.loggingEnabled", "false");
        System.setProperty("xr.util-logging.java.util.logging.ConsoleHandler.level",
"WARN");
        System.setProperty("xr.util-logging..level", "WARN");
        System.setProperty("xr.util-logging.plumbing.level", "WARN");
        System.setProperty("xr.util-logging.plumbing.config.level", "WARN");
        System.setProperty("xr.util-logging.plumbing.exception.level", "WARN");
        System.setProperty("xr.util-logging.plumbing.general.level", "WARN");
        System.setProperty("xr.util-logging.plumbing.init.level", "WARN");
        System.setProperty("xr.util-logging.plumbing.load.level", "WARN");
        System.setProperty("xr.util-logging.plumbing.load.xml-entities.level", "WARN");
        System.setProperty("xr.util-logging.plumbing.match.level", "WARN");
        System.setProperty("xr.util-logging.plumbing.cascade.level", "WARN");
        System.setProperty("xr.util-logging.plumbing.css-parse.level", "WARN");
        System.setProperty("xr.util-logging.plumbing.layout.level", "WARN");
        System.setProperty("xr.util-logging.plumbing.render.level", "WARN");

        XRLog.setLoggingEnabled(false);

        ITextRenderer renderer = new ITextRenderer();
        
        try {
            DocumentBuilder builder =
DocumentBuilderFactory.newInstance().newDocumentBuilder();
            Document doc = builder.parse(new ByteArrayInputStream(contents));

            renderer.setDocument(doc, request.getRequestURL().toString());
            renderer.layout();
            
            File file = new File("/home/jeff/workspace/output.pdf");
            FileOutputStream output = new FileOutputStream(file);
            renderer.createPDF(output);
            
        } catch (Exception e) {
            throw new RuntimeException("not able to generate the pdf");
        }
    }


Nov 14, 2007
#8 dirk.mic...@googlemail.com
Thanks for the test code. Unfortunately it still does not work. The exception throw
is still the ServletException ("connection timed out"). In the debugger I found out
that the line of code that produces the error is

  Document doc = builder.parse(new ByteArrayInputStream(contents));

The error is definitely produced in the parse method of the builder. As environment I
installed a clean room Tomcat 5.5.20 server. For testing purposes I changed the log
level of your code to ALL and added a e.printStackTrace() before the RuntimeException
is thrown. The console output is added as an attachment (console.log). This may help
you analysing the problem.

console.log
66.3 KB   View   Download
Nov 14, 2007
#9 dirk.mic...@googlemail.com
Meanwhile I found out that the problem is caused by the parser that wants to call
home to www.w3.org via internet while it parses the document. That call seems to be
captured by our firewall.

Is there any way to tell the parser not to verify the document?
Nov 14, 2007
#10 extremec...@gmail.com
Interesting...I was just going to get back with you too. 

I am having other problems with the PDF as well. I am able to view it when I use that
test code to put it out to a local file, but not when I send it out to the response.

The developer that created that view is looking into it today. 
Status: Started
Nov 14, 2007
#11 extremec...@gmail.com
If you look in the PdfView file you will see that that is where the call happens.
That is a pretty typical thing for a html document. Do you generally run without a
doctype declaration on your website?


I found out my problem with the PDF was related to the new stylesheet.

The following new styling breaks it:

.jmesa .odd td {
    border: 1px solid #ffffff;
}

.jmesa .even td {
    border: 1px solid #e3e3e3;
}

Nov 14, 2007
#12 fuzzbi...@gmail.com
See  issue 58  for a fix for the PDF export with enhancements.
Nov 14, 2007
#13 extremec...@gmail.com
I included the changes. In addition I moved the doctype to the preferences file so
that the doctype could be modified, or blanked out.

pdf.css=/css/jmesa-pdf.css
pdf.doctype=<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Would you be interested in helping out in testing this? If so I could do a build of
the project and the example web site.

Nov 14, 2007
#14 dirk.mic...@googlemail.com
Sure I would!
Nov 15, 2007
#15 extremec...@gmail.com
I put a build in the downloads:

http://builds.jmesa.org/

They are the builds that begin with jmesa-2.2.4-pdf. Let me know if you have any
problems or questions.
Nov 15, 2007
#16 dirk.mic...@googlemail.com
Now I have tested the new build and it's like always in life: I have good news and I
have bad news.

The good news are that when I run the basic president example on my home computer,
the two outputs (saved and downloaded) are valid PDF documents and they are
byte-equal. So from your point of view your job seems to be done - many thanks so far.

The bad news are that the parser of the DocumentBuilder still tries to connect to
www.w3.org which is blocked by the firewall of my company. The only thing that
changed is the exception that is thrown. It is not the ServletException anymore but
it's a java.net.ConnectException (stacktrace is attached as file). I think you can
easily reproduce this problem if you unplug your network cable before running the
example (then it's an UnknownHostException).

It seems the DocumentBuilder tries to validate the xmlschema. I already tried to
download the DTDs from w3c and to put them into the WEB-INF directory of the
application. But that didn't work. Do you have any ideas what else I can do to get
the PDF export working?

stacktrace.log
4.5 KB   View   Download
Nov 16, 2007
#17 extremec...@gmail.com
In the WEB-INF/jmesa.properties file declare the pdf.doctype attribute and keep the
doctype as blank. The jmesa.properties file is the Preferences file. What you are
doing is overriding the default.

pdf.doctype=
Nov 16, 2007
#18 dirk.mic...@googlemail.com
Thank you very much! Now it works like a charm. :-)

Nov 16, 2007
#19 extremec...@gmail.com
Thats great news! I will close this issue out then...it will be part of the 2.2.5
upcoming release (probably a week or so out).

I will write up a wiki page to make the export features more clear.

Status: Fixed

Powered by Google Project Hosting