January 4, 2012 at 22:17#26647
Like many people these days I use .jspx files.
I have successfully made a perfectly rendered .pdf file by using the pd4ml:transform tag in a classic ‘apache tiles’ default.jspx file.
As you may know, the default.jspx file is a useful shell that you can place round any number of other nested .jspx files.
In fact for this reason the default.jspx file would be a perfect place to put my pd4ml:transform tags, where I would use the ‘enable’ attribute to turn pdf production on and off.
Unfortunately only ‘enable=true’ works.
If I use ‘enable=false’, I get the dreaded error:
‘getOutputStream() has already been called for this response’.
I have of course read your faqs and know that the transform tag should be placed in a position where any possible white spaces before it have been removed.
Unfortunately however .jspx files insist on outputting the root xml tag before the transform tag can kick in (I can see this in the compiled class for the .jspx file) but this is only a problem when enable=false. And I need the root xml tag because it contains the url of the .tld file for pd4ml.
Firstly I was just wondering why there is this problem, because obviously pd4ml should be quiet and mind its own business when enable=false.
Secondly just wondering if you can think of any possible solution for this.
Thank you for your time.January 24, 2012 at 09:08#28753
Perhaps my question was too complicated.
The real question is:
Has anybody successfully created .pdfs from .jspx files and Apache Tiles?
If so please post an example, it would be greatly appreciated.
I can’t get pd4ml:transform to work with enable=false, only with enable=true.
With enabled=false I get the ‘outputstream already called’ error
Thank you for your time.January 24, 2012 at 11:44#28754
Could you please publish a sample of your .jspx page?January 24, 2012 at 13:58#28755
I have the latest version of pd4ml 3.8.0
Here’s the code (just change enable to “true” and it produces a .pdf, but with enable=”false” I get the exception):
OK, now try to substitute all occurrences of “pd4ml:” with “pd4mlXXX”, try to open the page in a web browser and open the generated HTML document source.
Are there any whitespaces before
?February 6, 2012 at 13:30#28757
Ok, done that.
.jspx files always put the xml version line and the doctype declaration, right at the top, followed by new lines.
<?xml version="1.0" encoding="UTF-8"?><br /> <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml-strict.dtd"><br /> <root>…..
element begins there are no white spaces.
You can remove the top xml declaration by including this in the .jspx file
<jsp:output omit-xml-declaration="yes" />
and I can remove the doctype declaration if I want to by excluding this line from the code:
<jsp:output doctype-root-element="HTML" doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml-strict.dtd"/>
which I did, even though obviously these days a doc-type declaration is important.
Doing that I have source without any white spaces before the transform tag.
But it still doesn’t work if I put enabled=”false”.
Please also bear in mind that with enabled=”true” and without omitting the doc-type or any other attempted hack, it produces perfect .pdfs. The only problem is enabled=”false”.
But for me the enabled true/false functionality would be fundamental.
Thanks for your help and time.February 6, 2012 at 13:34#28758
Just wondering if you can give me any news at all about this.
We’ve invested a lot in .jspx files and this unexpected problem is holding us up quite a bit.
Have you verified the problem and is this something that can be solved?
Any news would be gratefully received, thanks, so that I can decide what to do.February 6, 2012 at 15:55#28759
> even though obviously these days a doc-type declaration is important.
Not in PD4ML scenario. By a PDF generation the browser expects to receive PDF bytes only. If the response is leaded by the XML declaration, first: the data is misleading, as it is not “xhtml-strict” in fact; second: the declaration bytes break all object offsets in the document. Acroread can recover it on-a-fly, but it is not safe and by slow systems a pop-up with “rebuilding xref table” (or something like that) may appear.
PD4ML itself simply ignores the declaration.
The enable=”false” issue is in our TODO list for the next beta.February 7, 2012 at 15:05#28760
Thank you very much for your reply.
If possible I’d like an email advice for the beta once the fix is available.
Thanks again.August 26, 2014 at 09:32#28761
Was this ever fixed?
I had hoped to get an email advice, but never got one.
I suppose I shall have to buy 3.9, but if I do, can you confirm that the enabled parameter will work?
ThanksAugust 26, 2014 at 12:11#28762
As I see the patch still has not been applied to the main dev branch. Request support pd4ml com for a trial. If it fixes the problem, we’ll provide you with a patched commercial version after a purchase. (And of course the patch will be integrated to forthcoming versions)
The forum ‘Troubleshooting’ is closed to new topics and replies.