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 197: PDF export issue in Struts2
2 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  ----
Closed:  Oct 2009


 
Reported by rkri...@gmail.com, May 19, 2009
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
I totally missed this post! Did you ever find a solution?
Jun 1, 2009
#2 rkri...@gmail.com
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
Project Member #3 jeff.johnston.mn@gmail.com
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
#4 rkri...@gmail.com
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
Project Member #5 jeff.johnston.mn@gmail.com
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
#6 rkri...@gmail.com
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
#7 Vena...@gmail.com
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
screen1.png
112 KB   View   Download
screen2.png
133 KB   View   Download
Jun 15, 2009
#8 AlejaV...@gmail.com
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
#9 AlejaV...@gmail.com
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
#10 Vena...@gmail.com
This fix work for me.
To confirm
JMesa197.patch
1.1 KB   View   Download
Jul 13, 2009
Project Member #11 jeff.johnston.mn@gmail.com
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
#12 Vena...@gmail.com
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
Project Member #13 jeff.johnston.mn@gmail.com
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
#14 Vena...@gmail.com
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
Project Member #15 jeff.johnston.mn@gmail.com
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
Project Member #16 jeff.johnston.mn@gmail.com
Just defaulting the value now.
Status: Fixed

Powered by Google Project Hosting