Just a quick little post here. A reader contacted me a few days ago with an observation about a change to debugging in ColdFusion 9. In earlier versions of ColdFusion, if debugging was turned on and you ran a CFC (for example, making an AJAX call to a CFC method), debugging text was returned along with your result. This was almost always a bad thing as it tended to break AJAX applications. However, this reader actually used the debugging information to check how well their CFC was performing. Also - tools like ColdFire could make use of this data.
Well, in ColdFusion 9, debugging information is always going to be disabled for CFC calls. To be clear, I'm talking about the request to the CFC directly. If you write a CFM that calls the CFC, then debugging information will correctly include any activity within the CFC methods call. (And in fact, this is what the reader is doing to now.)
Archived Comments
Ah yep - I've seen this in mxUnit, and always wondered why.
If you click on a specific test, it goes directly to the CFC, so you never get the debugging. At least now I know I'm not totally crazy :) Thanks for the confirmation Ray!
No problem, and I should clarify, I went to Adobe (heh, that's me soon ;) to verify this was intended. It wasn't accidental.
Ah! This had me thinking I was going loopy!
It's annoying.
Is there any way to make it work as per before? It's handy to have it on when running MXUnit tests sometimes, and I believe it should be MY decision as to whether I have debugging switched on or not: I'm a big enough boy to switch debugging on and off as and when necessary. It's annoying to have that freedom taken away from me.
I have to say that with this and the CFABORT/CFLOCATION bug that has bitten me on the bum this week, I am not finding myself particularly happy with your new employers, Ray.
:-|
--
Adam
I honestly think it was a matter of 900 people fussing their Ajax was broken (even when it was their fault) versus 2 people who actually liked this. Now - that being said - you are the second person to mention using it via mxunit. Best I can suggest is file an ER for it and get folks to vote it up. Maybe the logic can be if cfsetting showdebugoutput=true is on in the CFC, it works. That way you would have to go out of your way a bit, but it would work.
As an experiment, I wrote an onRequestEnd that did this:
<cfinclude template="/WEB-INF/debug/classic.cfm">
and this fails here:
<cfset qEvents = cfdebugger.getDebugger().getData()>
Because getDebugger() returned null. So it looks like Adobe killed the access at a real low level. Now I'm curious if this broke debugging in CFB as well.
Nah, CFB debugging works fine. That was kind of a dumb test I guess. :)
Ah, This is what I usually do to check performance of CFC. Created test page which parse CFC's ajax request URL and called it based on passed arguments in URL.
This change should not - afaik - impact the Server Monitor too. So if you have slow queries in your CFCs - they should still show up.
Thank you for looking into this Ray. Interesting to see Adobe went to such a low level to kill the access.
Btw, I've added this as Bug/ER 86966 if anyone else wants to vote for this. (Hopefully I filled everything in right. Never submitted and ER to Adobe before).
I've voted for the bug: http://cfbugs.adobe.com/cfb....
Ray, I know what you mean about 900 people getting confused and only two people "liking" it, but that's specious for a coupla reasons:
* that debugging output on CFC requests was not "a problem", the problem was that the people getting confused by it are muppets. It's not for Adobe to fix that.
* people who use this functionality as it was will not email Adobe and go "hey, cool, that still works as expected: thanks for that". So it's a meaningless metric to mention the 900 vs 2 people. I know you did not mean to suggest it was a statistically sound or meaningful analysis, but it probably actually *was* Adobe's rationale for "fixing" it.
Basically this was a stupid way of dealing with a non-problem.
And it should be backed out.
--
Adam
Fair enough point Adam. And it's getting my vote too.
At my workplace AJAX call data has comments (START-END) around the data, and the content is stripped from between them by the javascript, nobody realised you could cfcontent reset and showdebug=no with a cfabort if required. I can see both sides but I'd much prefer to decide myself, so voted for this.
Thanks Ray for all your work supporting ColdFusion developers.
As a newcomer to ColdFusion (started last year), I've only worked with CFCs directly from Flex. I guess this means that I'm going to have to write some debugging CFMs unless we're spoiled once more by the easy integration between Flex & CF.
Actually you can debug the CFC without writing a CFM. Just open the CFC with a browser, select the method and enter the parameters in the URL. Gets messy for complex parameters.
That works in CF8 and prior, but as of CF9, no debug information outputs when executing a CFC using the URL method (hence the reason I submitted the ER/bug). Are you running CF9?
@Tomas: Ditto Lando. The entire point of this entry is about that change. ;)
Actually yes, it does work with CF9 through the URL as long as access="remote". For example, I type http://localhost:8500/QPMServerCF/CFAssetPropertyService.cfc?method=getPropertiesFromShipItemWithId&siteid=2&ruta=520&boxid=3539 and get a bunch of warbled text followed by the reports that Ray describes in his recent Adobe video, but without having to write the CFM.
Thanks to everybody
Maybe it's 901. Are you on 9.0? Obviously all of us can't be wrong here. ;)
This is what I'm doing (QuickTime video): http://www.scamecanica.com/... to debug my CF app.
That video doesn't show what version of CF you are running.
I'm pretty sure (80%, say) it came in with 9.0.1.
--
Adam
Here's the info. Thanks
Debugging Information
ColdFusion Server Developer 9,0,0,251028
Template /QPMServerCF/CFAssetPropertyService.cfc
Time Stamp 12-Nov-11 04:20 PM
Locale English (US)
User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8) AppleWebKit/534.50.2 (KHTML, like Gecko) Version/5.0.6 Safari/533.22.3
Remote IP 127.0.0.1
Host Name localhost
That would be 9.0, not 9.0.1. :)
Worth mentioning that my experience with ColdFusion so far has been great. Everything that could've gone wrong (this, for example) has gone right and the productivity achieved with this software (server + CF Builder) is incredible (as admitted by someone who sits next to me and works with php). We've already had one customer buy a server license and are expecting more down the road. Thanks again
Sweet. Love to hear people loving CF. Keep on - it just gets better!
p.s. I may be biased. Nah, I'm not.
Raymond,
who at Adobe confirmed that this was as of 9.0.1? I can't tell, by the release notes, that it was part of that release.
We use the SQL Query debug information all the time via Charles Proxy to determine what queries were run for a given AMF request....or we did, until we upgraded from 8 to 9.0.1...
Are you asking where it is documented? If so - I don't know. Unfortunately there is no way to toggle this off. It is what it is.
Ray - I'm trying to build a script that would dynamically change the getDebugTemplate value from false to true. what I currently have is not working as Coldfusion is telling me that I can't change the value of a function. Here is what I got:
<cfset dbObj.getDebugTemplate() = true>
What you run into this in the past? Any help would be appreciated
I do not see that API in CF10. I don't have CF9 anymore to test. In general though that's now how you use functions.
<cfset smething.somefunc(value)>
hey Ray - Thanks for the response and looking into this. I'm actually using CF10, basically what I'm trying to do is to dynamically change the robust error reporting based on IP address. I tried approaching it by setting up the Java object but got an error in CF. Have you tried anything like this before?
ColdFusion 10 added this.enableRobustException=true/false to the Application.cfc file. You could try logic like this in App.cfc:
if(some condition) this.enableRobustException=true;
else this.enableRobustException=false;
That may work. Don't forget too that if you are using proper error handling (ala onError), you can do if(somecondition) cfdump the error and get the exact same info.