I'm currently experiencing a very weird issue with CFDOCUMENT.
One of my clients is running a large CF infrastructure. For
various reasons, it was decided to upgrade the different
systems (local developer machines, dev sever, staging and
producation) from CF 7 (or CF 7.0.1 - there was no consistency)
to CF 7.0.2 (note: we're talking about CF running as a J2EE
instance on a full-blown Jrun 4) with hotfix hf702-62335.jar
installed (to fix a few CFDOCUMENT issues in the original
CF 7.0.2). HTTP server is IIS 6, all server machines run
on W2k3 server, the developer machines Win XP.
The upgrade went totally smooth in all environment except
(guess what) production. Since installing the update to
7.0.2, CFDOCUMENT just doesn't work at all on production.
Even simple stuff such as:
doesn't not work anymore.
The behaviour I'm seeing here is that the pages just time
out with CF's default timeout value (6000 secs here) and
never executes. It also doesn't make a difference if we
try to write the pdf to the file system, I've experimented
with the fontembed property as well as with creating a
The Application.cfm of this app uses CFError to email me
the error struct, and what I basically get from there is:
The document has no pages. null <br>The error occurred on line 1.
ExceptionConverter: java.io.IOException: The document has no pages.
at com.lowagie.text.pdf.PdfPages.writePageTree(Unknown Source) at
com.lowagie.text.pdf.PdfWriter.close(Unknown Source) at
com.lowagie.text.pdf.PdfDocument.close(Unknown Source) at
com.lowagie.text.Document.close(Unknown Source) at
at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:152) at
at coldfusion.filter.PathFilter.invoke(PathFilter.java:86) at
The stack trace apparently points to the issue that the pdf content
never gets written into a temporary file or stream to the browser.
Removing the hotfix totally or replacing it with the cumulative hotfix
for 7.0.2 doesn't make a difference.
Have done some investigations and looking at reports of people
having reported similar issues before, those were either
related to a very clear issue (watermark file missing, using
images in their CFDocument) or way pre CF 7.0.2. I'm running a
bit out of ideas on this one now ;)
Anyone able to provide a good suggestion what else to look into? I'm
wondering if it could be some sort of an access rights issue. Does
CFDocument write anything into a temporary file somewhere during the
creation of a pdf to be delivered directly to the browser?
thx, had tried that before, didn't make any difference.
@AJ: FlashPaper doesn't work either, we've rebooted the machine as
well as have cleared the template
cache before each single test, deleted class files in the cfclasses
Debug is enabled on some of the developer machines and the dev
Not on staging or production, and the issue just occurs on production.
Try a real html page cutup into chunks and wrapped in cfsavecontent.
Advertisement: Your Future Starts Here. Dream it? Then be it! Find it at
I really don't think that this is an issue of the way CFDocument is
used here. I'm currently investigating in the directions of wrongly or
to tightly set permissions on the production environment and also
looking into potential issues that could have made the update fail/go
Does anyone know if CFDocument writes into a temp folder while being
executed? Maybe somewhere hidden in WEB-INF...?
I know you mentioned that you saw this error report, but I'm guessing
that maybe it's still required even though you're in production mode.
This is slightly off topic, but cfdocument seems a little
finicky/buggy to me. In particular I've had big problems with
formatting Chinese characters and also in testing our CRM app under
scorpio, i noticed some strange behaviour. A var scoped CFC instance
created outside a cfdocument tag just disappeared when trying to
reference it inside the cfdocument tag. It threw a variable not found
Also the formatting has change quite a bit in Scorpio, but i think
it's for the better. It seems to be more consistent in appearance.
However, it means we'll need to adjust all the formatting for our doc
generators when it comes time to upgrade.