Highlighted

The type for attribute format of tag document could not be determined

Explorer ,
Mar 08, 2020

Copy link to clipboard

Copied

In my application, I am getting an error saying "The type for attribute format of tag document could not be determined". This is happening during PDF generation using cfdocument tag. Note that we are working with PDF files in Memory (ie , we are using the coldfusion option to write a PDF file to a variable by using the name attribute). Attaching the stack trace here.

 

Capture.PNG

Views

405

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

The type for attribute format of tag document could not be determined

Explorer ,
Mar 08, 2020

Copy link to clipboard

Copied

In my application, I am getting an error saying "The type for attribute format of tag document could not be determined". This is happening during PDF generation using cfdocument tag. Note that we are working with PDF files in Memory (ie , we are using the coldfusion option to write a PDF file to a variable by using the name attribute). Attaching the stack trace here.

 

Capture.PNG

Views

406

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Mar 08, 2020 0
Adobe Community Professional ,
Mar 09, 2020

Copy link to clipboard

Copied

Abdul, the error says that you have not set a valid value for the "format" attribute of the cfdocument tag. You say you want a pdf, so you need to add format="pdf", as indicated in the cf docs for the tag.

 

Or do you think you are doing that already? 

/Charlie (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 09, 2020 0
Explorer ,
Mar 09, 2020

Copy link to clipboard

Copied

Thanks Charlie for your response. Yes we do this via attributeCollection as below,

 

<cfset attributes.attrCollection = {
fontembed="true",
localUrl="yes",
format="PDF",
pagetype="A4",
unit="cm",
pageWidth="21",
pageHeight="29.7",
marginleft="0",
marginright="0",
margintop="5",
overwrite="true",
bookmark="true"
} />

 

The above variable we set to attributes scope since we generate PDF in CF thread. Also please note that when we try regenerating pdf 2 or 3 times this issuse never happens.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 09, 2020 0
Adobe Community Professional ,
Mar 09, 2020

Copy link to clipboard

Copied

OK, interesting. So first, wrap the cfdocument in a try/catch, and when it fails, dump out the attributes scope. You may well find that somehow it's NOT got the values that you think it does--in that moment. And in seeing what IS (or is NOT ) in the dump, you may better be able to tell where the problem is happening.

 

Second, if that doesn't get you anywhere, you could try a different scope than attributes. I do realize that the attributes scope is what's recommended by Adobe (such as here, https://helpx.adobe.com/coldfusion/developing-applications/developing-cfml-applications/using-coldfu..., even thought it's something that was creatd for use with CFML custom tags, an old concept).

 

But just as a sanity-check, what if you used the "request" scope instead? The doc there indicates that it would be supported. I realize the docs indicate that CF supposedly adds single-thread protection to use of the attributes scope, but I'm just throwing out an idea.

 

Indeed, finally, you say that "when we try regenerating pdf 2 or 3 times this issuse never happens." Can you clarify what you mean? Is it that this error only happens on the first call to create the PDF, but not subsequent ones? Is that about multiple calls in your browser to the same request, over and over? Or do you mean that within the code of this page, if called only once, it somehow sets things up to call multiple PDF generation actions? However you answer, that may be a clue as to why the problem happens. It sure sounds like some sort of race condition (despite the supposed protection of the attributes scope, mentioned in that doc page I linked to.)

 

WIll be interested to see how things sort out.

/Charlie (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 09, 2020 0
Explorer ,
Mar 15, 2020

Copy link to clipboard

Copied

Sorry for being late to respond. In my further analysis, what we found is that this issue is happening only in a particular CF instance. We have 20 CF instances in a server. When we regenerate the PDF and if the regeneration happens on other CF instances this issue never occurs.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 15, 2020 0
Adobe Community Professional ,
Mar 16, 2020

Copy link to clipboard

Copied

That's interesting, but none of it negates the diagnostic approaches I offered in my last response. Have you tried any of them? Or do you mean that the fact it happens on only one server has led you or someone to deem that you don't want to try to solve or understand it?

 

If your conclusion is that "we think there must be something wrong with that one server", well, that may be so. It will be hard to diagnose that remotely. I would propose you could make 100% sure that all the CF Admin settings and jvm config args are the same.

 

And you could make sure there's no error in the running of any CF updates that you applied (there is a log for each update, in the CF hf-updates folder when you apply each update). I have a blog post on that with more details:

https://coldfusion.adobe.com/2019/03/problems-applying-cf-update-check-first/

 

But I'm hoping you may get to try the above to see what's up. It could be some coding issue that has a failure only on the one server, for some reason, and working backwards from that may get you to the solution, if the above ideas don't bear fruit.

 

Please do keep us posted/

/Charlie (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 16, 2020 0
Explorer ,
Mar 17, 2020

Copy link to clipboard

Copied

I mentioned that issue is with only one particular instance of a server. Not with a server itself.

 

We have 20 instances (Say x1,x2......x20) in a CF server (CF 2018). Each of these instances pointing to the same code set. Now the issue is only with x16. There is no issues with other instances. If there is a code issue then we should get the same issue with all the instances right , since all the instances are pointing to the same code set.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 17, 2020 0
Adobe Community Professional ,
Mar 17, 2020

Copy link to clipboard

Copied

Abdul, replace the word  "server" with "instance" in my last reply, and all I said still applies--ESPECIALLY the first paragraph, which I plead for you to try. 

/Charlie (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 17, 2020 0