You will be redirected in 30 seconds or close now.

ColdFusion Authors: Yakov Fain, Jeremy Geelan, Maureen O'Gara, Nancy Y. Nee, Tad Anderson

Related Topics: ColdFusion

ColdFusion: Article



Have you ever wanted to see what lines of code are being executed in your template? If you looked for CFTRACE to do that, you were likely disappointed. The CFDEBUGGER tag in BlueDragon, however, can be a great tool for debugging.

When CFML developers need to figure out what their code is doing, in terms of what lines of code their template is executing, they have surprisingly few options. There are other debugging tools, but they address different needs.

There's the server debugging info, but that's all after the fact, simply showing the state of variables at the end of the program (and/or in some cases their values when passed into it). And many rely on a trusty combination of CFABORT and CFDUMP to help identify control flow issues and other debugging challenges.

There's also the new CFTRACE tag introduced in CFMX and the older CFLOG tag from CF 4; each offers interesting variants on enabling you to track the value of some variables or log some string at a point in time. But neither of these can be used to simply show what lines of code have been executed in a run of a template. And the Java-based stack trace doesn't solve this problem either.

The closest we had was the interactive debugging tool of CF Studio that worked with CF 5, but is no longer supported in CFMX. Even then, many found the interactive debugger to be lacking and often not usable.

If you simply wanted to get some listing of all the lines of code that were executed in a template (what some really would call a "trace"), there's currently no solution in CFML unless you use BlueDragon. In this month's Blueprints column I'd like to introduce this feature that could be useful to all CFML developers.

CFDEBUGGER: It's There If You Need It
<CFDEBUGGER> is a tag that works in BlueDragon only, and it simply writes an indication of each CFML line of code that's been executed to a log file. That's something many have long wished for. There are times when this is just the ticket to solve a challenging debugging problem. Here's a simple example of its use. Let's say you have a template that just does this:

<cfset name="bob">

Note that no closing CFDEBUGGER tag is needed (as will be explained later). This will create an entry in a file named trace.log (as indicated in the LOGFILE attribute) with the following info:

#0: CFDEBUGGER trace started @ 19/Aug/200315:03.19
#1: active.file=C:/Inetpub/wwwroot/regression/cfdebugger.cfm
#2: tag.end=CFDEBUGGER; L/C=(1,1); File=C:/
#3: tag.start=CFSET; L/C=(2,1); File=C:/Inetpub/
#4: tag.end=CFSET; L/C=(2,1); File=C:/Inetpub/
#5: file.end=C:/Inetpub/wwwroot/regression/cfdebugger.cfm
#6: Session Ended

Note that it indicates the time the template was run and the template's name, which is useful because the log could hold lots of such "trace sessions," for reasons I'll explain in a moment. More important, for each CFML tag it encounters, the trace shows its start and end lines in the given template. Unlike looking in an editor, this log shows only lines with CFML tags that were executed, not all lines in the entire file.

And while the CFML error message (in both BlueDragon and CF) reports the line of code on which an error occurs, what if the problem is a logic error that's not generating any CFML errors?

This capability could be useful for debugging a knotty problem where you can't tell which lines of code are being executed. If this was a several-hundredline program doing loops and ifs, it could help you quickly narrow down just where the flow of control was going if you were having trouble figuring it out. Sometimes even well-placed CFOUTPUTs, CFDUMPs, and CFABORTs just don't do the trick.

I'll grant that it could produce a lot of data to analyze (and sadly it's not in a format that's easily conducive to performing automated analysis), but there will be times when it's better than nothing.

And it's something that CF has never had. Did you perhaps think that this was what CFTRACE would or should have done? It doesn't. CFTRACE (introduced in CFMX) just writes the value of a given variable or string to either a log file, the debugging output, or the screen. It's just a little more useful than CFLOG or CFDUMP. (BlueDragon currently supports CFLOG and will eventually support CFTRACE.)

So CFDEBUGGER could be very handy when you need it. Give it a try. Just be careful not to leave it on lest it create humongous log files.

Here are some additional notes about the use of CFDEBUGGER.

Where Is the Trace File Stored?
In the example I showed, I didn't name the path for the location to the log file. Where does it go then?

In the Server editions of BlueDragon, it's stored in the BlueDragon install directory. For instance, if you're using BlueDragon Server JX and it's installed in C:Program FilesNew AtlantaBlueDragon_Server_JX_ 3.1, that's where you'll find the log file.

In the J2EE edition, the actual location will depend on the J2EE app server you're using. I've not found any logic to explain where the server decides to put it. It's neither the application's context root nor the install directory for the app server. For instance, in my WebLogic 8.1 test, it was found in C:eauser_projectsdomains mydomain. In JBoss, I found it in C:jboss-3.2.1_tomcat- 4.1.24in. In JRun, it was in my C:JRun4in. If you have another server, just do a search within that server's directory for whatever you named the file (you're free to call it what you want), and make note of that location for future reference.

Can I Provide a Full Path for the Log File?
Rather than wondering where it may be stored, you can also just name the full path to the intended directory for placing the file. For example, using LOGFILE="c: race.log" works as expected, and in both the Server and J2EE edition.

What Happens If You Do a CFINCLUDE or Custom Tag Call While Tracing?
No problem. The trace log will continue to log all the activity (hopefully that's what you wanted). The log file does indicate when you switch to running a new template. At the point of the cfinclude, you'd see an entry like this:

#6: file.start=C:/Inetpub/wwwroot/includedfile.cfm

where in this example my calling template included a file called includedfile.cfm. That's useful.The same is true when calling a custom tag.

When Does Tracing Begin?
The tracing begins at the point that the CFDEBUGGER tag appears. Therefore, it will not trace activity in the application.cfm that occurs before you start tracing. Naturally, if you place the CFDEBUGGER tag in the application.cfm, then indeed it will do the tracing from that point forward (as I just said above, the tracing does remain in effect across includes and custom tags, and application. cfm is executed like an implicit cfinclude before any template runs, so the same logic applies).

When Does the Tracing Stop?
Tracing ends at request termination (of course, if you have an onrequestend.cfm, it will trace that as well). As will be discussed, while tracing stops at the end of request execution, the log file is not emptied upon each new request.

Is There a Way to Turn Off Tracing?
In other words, if a calling/including template or the application. cfm starts the tracing, is there a way to stop it in the called/included/requested program? No, currently there is not. And again, there is currently no available closing CFDEBUGGER tag to surround code to be traced. If you don't want to do the tracing, you should just remove the CFDEBUGGER tag.

If a template is running under the influence of another that turns tracing on within the current request, you'll just need to remove the CFDEBUGGER from that controlling template if you don't want it to trace any that it includes/calls/requests.

You might wonder if you could solve the problem another way - perhaps by leaving the LOGFILE attribute value empty or leaving it off entirely, hoping it will turn the logging off. That doesn't work and will instead get an error. I suppose in Linux boxes you could redirect the tracing to the null device, though. Again there's no way to stop tracing within a request once it's started for a given request, short of removing the CFDEBUGGER tag.

Is a New Trace File Created on Each Request?
No, and this is very important. The trace files are cumulative. They are appended to by each request that writes to them. Beware, therefore, as they can grow quite large with successive executions. Don't forget to remove the CFDEBUGGER when no longer doing tracing. There is currently no attribute to cause the tag to erase existing log entries or otherwise manage the log file size. (It does create one if it doesn't exist the first time you call it.)

What Happens When a New CFDEBUGGER Is Encountered Naming a New Log File?
In other words, what happens if one template (such as application.cfm or a calling/including template) has turned on the tracing to one file, and another template (or even later code in the same template) offers a new CFDEBUGGER naming a new log file? Tracing simply stops on the first log file and continues with the newly named one. That could be useful (or it could be a hassle in some instances, but that's the way it currently works).

Does CFDEBUGGER Trace Functions As Well? Or Just Tags?
It currently traces just tags, not references to expressions within tags. For instance, consider the following code:

this is a test
another line

It might be nice if it reported encountering the variable and function references on the 4th and 6th lines. It does not, reporting only on the opening and closing CFOUTPUT tag. The same would apply to expression references within CFMAIL, etc., as well as statements within CFSCRIPT. These are not individually traced.

(There's a TagsOnly attribute available for the tag, designed to take a yes/no value, which was perhaps intended to solve this problem, but it's not currently implemented.) It's not really a big deal if you think about it, at least with respect to CFOUTPUT and CFMAIL. The value of detecting the flow of control within these tags would seem somewhat diminished.

One last question that some may wonder about: Is it risky for BlueDragon to add a tag like CFDEBUGGER to CFML? Does it make your code incompatible? Look at it this way: you wouldn't leave the CFDEBUGGER tag in a production CFML application. You'll only use it for debugging purposes, so there's really no risk to your using it and therefore our adding it.

Some Possible Improvements
I have alluded to some challenges of using the CFDEBUGGER tag. It's not perfect. While it's useful now, perhaps as more people take advantage of this nifty tag, New Atlanta can consider improving it. Here are some possible improvements I'd look forward to:

  • Change the log output format into a CSV file or the like (at least, give us the option) so that New Atlanta could then perform analysis on the output. For instance, it would only be a short step to then be able to produce a report indicating which lines of code were executed the most.
  • Write out the time taken to execute each tag. Again, this could then feed into an analysis reporting not by frequency of execution but by total time per line of code. That could be really cool.
  • Offer a means to turn off tracing, in case it was enabled in a calling/including template or application.cfm and you don't want it continuing in an included/called/requested template.
  • Cause it to create a new log file on each new request (rather than growing unchecked), or a way to indicate a maximum number of requests to keep or a maximum size the log file should grow, or perhaps an attribute to indicate that the log should be wiped clean before being written to for the current request.
  • Have the tagsonly work as it would seem it should, letting it trace the lines containing variable and function references.
  • Add an attribute that indicates if it should only create its tracing output if the debugging option is turned on in the Admin. That way it could be left in place in production and not have any effect unless debugging is on, or you run it while debugging is enabled for your IP. CFTRACE works this way in CFMX, and our new CFASSERT tag that we've added to the latest release of BlueDragon works similarly (more on that in a later article). Supporting debugging tags to run only when debugging/testing is on is a good model. Then again, some may especially want it tracing while folks are running the template in production. That's why I think it should be controllable as an attribute.

    But, for now, enjoy what it does offer, which is a unique way to trace the lines of code being executed in a CFML template.

  • More Stories By Charlie Arehart

    A veteran ColdFusion developer since 1997, Charlie Arehart is a long-time contributor to the community and a recognized Adobe Community Expert. He's a certified Advanced CF Developer and Instructor for CF 4/5/6/7 and served as tech editor of CFDJ until 2003. Now an independent contractor (carehart.org) living in Alpharetta, GA, Charlie provides high-level troubleshooting/tuning assistance and training/mentoring for CF teams. He helps run the Online ColdFusion Meetup (coldfusionmeetup.com, an online CF user group), is a contributor to the CF8 WACK books by Ben Forta, and is frequently invited to speak at developer conferences and user groups worldwide.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    IoT & Smart Cities Stories
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
    The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
    CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
    DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
    All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
    Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
    Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
    The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
    SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...