| Issue 197: | PDF export issue in Struts2 | |
| 2 people starred this issue and may be notified of changes. | Back to list |
I'm using jmesa inside Struts2 with Sitemesh. When I create TableFacade with TableFacadeFactory.createStruts2TableFacade() method, PDF export doesn't work. Empty file (0B) is returned and I get "SEVERE: Not able to perform the PDF export." message in log (nothing more). When created with TableFacadeFactory.createTableFacade() PDF export works fine.
Jun 1, 2009
Project Member
#1
jeff.johnston.mn@gmail.com
Jun 1, 2009
No. I was trying to look at the jmesa source code but it doesn't make sense to me... (I mean, why this bug occurs, not the code itself :))
Jun 1, 2009
What version of JMesa are you using? The last release had some code in there to pull the DTD locally, which is what I would have said the problem was. You could try the PDFP export which is more basic but works better for some.
Jun 1, 2009
I am using latest 2.4.2 relase. I am pretty sure the problem is not in DTD lookup though. Actually, local fetching of DTD doesn't work for me out of the box. PDF export is downloading it from w3c.org and it takes usually ~5 seconds, but with successfull result.
Jun 2, 2009
For testing purposes does the PDFP export work? If not does the CSV export work...that is the simplest export there is.
Jun 2, 2009
All other exports work fine. I will try to come to you with more detailed bug reports (also regarding DTD lookup and encoding problem that I just discovered) soon.
Jun 10, 2009
I have the same bug, and after searchs I found that : The bug come from the update 2.4.2 : "Fixed PDF export" when he try to load dtd from "core-renderer-R8pre1.jar" with the "Tagsoup Parser". Data loaded are bad (file "screen1.png") The problem is that Tagsoup change attributs of XML to lower case and "core-renderer" don't understand it (file "screen2.png") Use ExportType.PDFP instead ExportType.PDF work but generated PDF are ugly
Jun 15, 2009
Hi there, almost same problem here. "Not able to perform the PDF export" in log. I just upgraded JMesa to 2.4.3 (with lot of problems because my tables were already working...) when I started to have problems downloading the DTD's for PDF exports, thinking that this last release would fix the problem. Well, the problem was replaced for other "more enigmatic" problem without trace or more information... I think i will try to downgrade jmesa again and fix the dtd problem in other way...
Jun 15, 2009
Ok, I did return to my stable jmesa 2.3.4 and fixed it "old style" way. With "pdf.doctype=" in jmesa.properties. Cheers,
Jun 16, 2009
This fix work for me. To confirm
Jul 13, 2009
I totally forgot to look at this! Sorry about that!
But I am on it now...I see that this patch involves declaring the
'xr.load.xml-reader' attribute twice. I assume that one overrides the other so I am
surprised that this would fix your issue. Could this be more about creating the
FSEntityResolver before setting the System properties? Or is it that the
FSEntityResolver is using the 'xr.load.xml-reader' 'default' value and then the other
values are used elsewhere? Maybe this should be in the preferences so that developers
can define it however they want?
System.setProperty("xr.load.xml-reader", "default");
FSEntityResolver er= FSEntityResolver.instance();
System.setProperty("xr.load.xml-reader", "org.ccil.cowan.tagsoup.Parser");
Any thoughts? Really sorry for missing this!
Status:
Accepted
Jul 15, 2009
The problem is that FSEntityResolver doesn't work with Tagsoup parser (case sensibility bug). So I decided to used the default Java parser which work fine. I override the 'xr.load.xml-reader' because I think than system property are memorized between different call but that may be wrong.
Jul 15, 2009
Does it matter when the FSEntityResolver is created for you? Would it work for you if
I left the FSEntityResolver where it is and then "xr.load.xml-reader" attribute to
say "default"?
System.setProperty("xr.load.xml-reader", "default");
//System.setProperty("xr.load.xml-reader", "org.ccil.cowan.tagsoup.Parser");
I think in general unless there is an appealing reason to not use the "default" I
would lean to using it for the value.
Jul 16, 2009
I try to simply remove
System.setProperty("xr.load.xml-reader", "org.ccil.cowan.tagsoup.Parser");
and that always works.
Replace "xr.load.xml-reader" attribute by "default" works too.
I see in code that PDF export is implemented in two places (ExportUtils &
PdfViewExporter). Is it normal?
And a last point, when you change system properties, it's may be safer to back to
previous value at the end of the function (some projects may define special XML parsers).
The function "System.setProperty(String, String)" return the previous value of the
system property, or null if it did not have one.
Jul 16, 2009
I bet the default would work fine... I had forgotten about the PDF export in the ExportUils. The reason I had that was for an easy way to export the file for debugging purposes. I will see about merging that code. Thank you for bringing it to my attention!
Status:
Started
Oct 20, 2009
Just defaulting the value now.
Status:
Fixed
|