[Looking for Charlie's main web site?]

FusionDebug Part 1: Why get excited?

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Since the announcement of FusionDebug a couple weeks ago, there's been relatively little other news or blogging about it. I think that's a real shame and I'd like to address that here in a series of entries introducing you to it, and sharing tips and traps.

I've just given a talk tonight at the Atlanta CFUG (which I'm open to presenting to other groups via Breeze, if not on-site should I be traveling there for other reasons.

Over the next few entries here I'd like to share some of the points I did in the presentation. I'll cover such things as FusionDebug features and some gotchas to watch out for, as well as answer some frequent questions.

But I'd like to start with why I think people should be excited.

What is interactive (step) debugging?

What do we mean by interactive or step debugging? It's not about the debugging output at the bottom of a CFML page. Instead, it's about single-stepping through the code line at a time, while being able to watch the values of expressions and variables--and even change variables on the fly.

Where do you stand on using debugging?

Have you ever used an interactive (step) debugger? They are common in other languages (Java, .NET, Javascript, Flex, Flash, and more). Since many CFML developers have not used those, they may not even miss a debugger. Similarly, there are some who know about them and still are not excited about them. To each his own. I think that most will indeed find value once they've used it.

Many don't know it, but there was indeed interactive debugging in CFML in CF 4 and 5, by way of CF Studio (or now HomeSite+). In a future entry I will talk about how you can demonstrate and use that (with CF4 and 5 only). But Macromedia/Adobe chose not to carry that feature forward into CFMX, so FusionDebug represents the first and only current way to do step debugging in CFML for CFMX (6 and 7).

As a commercial product, you can also take consolation that it will indeed work as advertised and if it doesn't that there will be a company behind it to help support, improve, and evangelize it.

About FusionDebug

FusionDebug is an Eclipse plug-in. Just like FlexBuilder is a commercial plug-in on top of the free Eclipse framework, so too is FusionDebug a commercial plug-in on top of Eclipse. It's priced at US$ 299, with an available 10% discount code (CFCOMMUNITY) as well as volume discounts. There is also a free 20-day trial. Your first response may be that you don't think you should have to pay for such a product, but with no debugging tools seemingly on the horizon from Adobe, it's really a rather small price to pay if you will benefit from debugging.

Your second response, if you don't use Eclipse currently, may be to worry about having to use it. First, note that you don't need to give up your favorite CFML editor (DWMX, CF Studio, HomeSite+, CFEclipse, or whatever). Further, it's easy to learn how to use the minimal amount of Eclipse functionality you need to understand to use FusionDebug.

You do need to download Eclipse (which is free), unless you already have it installed (for instance, if you have FlexBuilder or CFEclipse). The FusionDebug User Guide explains how to get and install it (which is very easy).

It also requires just a minor change in the jvm.config file for the CFML server that you'll be debugging against (again, easy to do as well-documented in the User Guide). Here you indicate a port that the debugger will listen on, and you then do a minor setup in Eclipse to enable debugging against that server (again, well-documented and simple).

In the next entry, I'll actually introduce the features that FusionDebug enables. In the meantime, if you're too excited to wait, you can can read about the features, including screenshots, or you can even view some Captivate videos.

In future entries, I have several hidden gems and gotchas that I'll share.

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Well, I tried to install FusionDebug and it completely corrupted my Eclipse setup and destroyed all my other plugins. I still haven't fully restored my development environment :(

As for step debugging, I think it's worthless. I haven't used a step debugger since I was a novice Pascal programmer back in the 80's. Actually, I tried them again in the 90's with C++ but still found them worthless.

I saw the announcement about this a while back and it did raise my interest. When I read the installation steps, I was somewhat put-off. After all, I had step debugging way back in the day (CF 4.5 or what have you) and tried it a few times but never found any value in it.

To be honest, Sean's comment is a relief. I just thought I was too dim to see the value.

That being said, I am curious to see what value a tool of that kind can offer.
Sean, I'm well aware of your disdain for debuggers. I had you in mind when I made the comment about those who do. :-) That said, I am indeed very sorry to hear about your problem with FD somehow leading to a corruption of your Eclipse setup.

Did the folks from Intergral identify the cause and solution to that problem? I'm sure they'd want very much to help. I do so hope you didn't just keep the problem to yourself in disdain. You and i both know that people have done that with CF (and BD and every software product), and while a sense of indignation offers some consolation, it does nothing to make the vendor prevent the problem happening to someone else.

Further, if such a problem is not reported, neither you nor the vendor knows how often it's happening (are you the only person to whom it's happened? Or does it happen to many who also have not reported it?) Let me say also that of course you may well have already reported it, which would be great. I'm sharing this response more for others who may also have problems with this or any software product. As the saying goes, "it's better to light one candle than to curse the darkness".

I hope things can be resolved for you, and I hope all the more that your bad experience won't happen to others--nor taint their interest in giving it a try. Such a threatening sounding experience could really scare others off. Just as we wouldn't want one bad experience for a CF user to be held against the product as a whole, I hope you and others will consider the same with FD. As I was going to write about in a later entry, my experience with them and their support so far has been stellar.
Steve, I'm surprised to hear you were put off by the installation steps. What part sounded daunting? It takes about 5 minutes to get started. If it's the editing of the JVM config, well, that may well challenge those on a shared host or in an environment where someone else controls the box, but since CF is a server product (and not just a locally running compiled language), it does require configuration of that server (wherever it is) to enable debugging.

As for Sean's comments, I sure do hope that people don't take too much consolation in his disdain. Seriously: we all know that some hold one framework in ill esteem (or the use of them at all), while many others will laud and praise another (or any at all). In the same regard, I really do hope people will give this a serious look.

As I said in the entry, and as you alluded to, we had CF debugging in the past, and some couldn't get it to work well, which soured their experience. I'm sure it's just a matter of time before people will begin to identify clear and obvious situations where step debugging was about the only way (or clearly the more effective way) to solve a problem. I have some in mind already, and will write of them in future entries.

In the meantime, I hope all will try it for themselves--and to those who may fear Sean's experience despite my hope that it's an isolated incident, here's something I didn't think to mention in my last comment: just create a new installation of Eclipse, rather than try to install it into an existing one. Installing Eclipse is drop dead simple (there's not even an installer, you just extract the zip into a directory). Once you're happy with it, then you can consider installing it also into your main Eclipse build.

Hope all this is helpful to some.
I want to ditto Charlie. When I had issues with the debugger I was able to get a pretty quick response from the developers. I'd defintely report it.

As a side note to Charlie's post - another good way to learn Eclipse, but more focused on CFEclipse, is the ACME guide from Stephen Collins:


This is the best darn PDF I've read in my life - in terms of usefulness I mean.

Honestly I don't remember for certain what the steps were. I believe it was the JVM configuration. I work with a variety of clients in different hosting situations (including shared) so I would effectively have to copy code to my local server to take advantage of the step debugging.

If I recall correctly, I was able to get the debugger in ColdFusion Studio working, I just didn't find a situation where it gave me any more benefit over cfdump (obviously not available then) and cfabort.

Again, none of this is to say that I am closed to learning more about step debugging or this product in particular. I am very interested to read more about it and perhaps find a way to get value of the approach that I haven't so far.
In response to Sean's corruption comment, I'd thought I'd mention that Eclipse gets corrupted /all the time/. At my place of work there are about 20 of us all using Eclipse for different reasons (Java, ColdFusion, Python) and it's rare that a week goes by that one of us doesn't have some problem with it after installing a plug-in or applying even a minor update. I've pretty much given-up on using Subversion with it after many problems with both Subversive and Subclipse. I keep several installs of Eclipse around and back it up every time before I install a new plugin / update anything now because it gets broken so easily and so frequently.

Integral does also provide very good support. While evaluating FusionReactor I had a few questions and they weren't afraid to give me the very low level details I was looking for without having to prompt them with a lot of questions.

However... I too have never found a use for step debugging outside of Assembler. It's nice to see what memory registers are doing when you're coding that closely to the hardware, but otherwise I can't say I've ever been in a situation where it's been handy in other languages I've used (C, Java, Python, CF). I think this is especially true with good OO programming.

Perhaps if there were something that could visualize concurrency interactively and point out threads stomping on each other via shared variables, but that's a whole different ball of wax.

What I would like to know is what benefit do I get from using FD as apposed to just using cfdump to dump all the scopes at the bottom of the page? I can see using a step debugger in .Net since the errors code can sometimes be totally confusing, but I have never encountered an error in CF that didn't give me a clear description of what exactly the problem is and where it was.

I think one of the big stumbling blocks to using FD will be the configuration of the JVM. I believe that if FD had a remote debug like VS.net does, then it would be more appealing. Most of the time you need a step debugger when something totally whacky is happening and usually this occurs when the application is in production.
Thanks, everyone, for the additional comments so far. Tony, to you and others, I will address your points in the future entries. :-) Let me say for now that I think people may be surprised by what's possible, such that past experience with (and limitations in) other debuggers may not apply.
Hi Everyone,

I just wanted to clear up that Sean did contact us and we have been working to understand the issue. This has been the only reported case of FD causing an issue in Eclipse from all of the downloads so far. Should any such issues arise further we will of course do our best to resolve them as quickly as possible. Thanks to everyone for their comments and inputs.
# Posted By Darren | 9/7/06 2:58 PM
With all this negative feedback, I feel the need to stand up as one who has actually had the thought "gee...this would be a lot easier to debug if I could go step by step". Am I really the only one who has ever gone through code, basically step by step, cutting and pasting in a <cfoutput>#variable#</cfoutput> to figure out where I'm losing/changing a variable? I've spent hundreds of hours doing this, especially when it comes to figuring out security frameworks and session variables.

It seems like this can only be a good thing to make CF even easier to use. I certainly appreciate hearing about bad experiences with installation and configuration, but I don't really care who likes the idea of a step debugger and who doesn't, because I know there would be value in this product for me. Thanks for the prompt Charlie. I'm definitely going to check it out, and look forward to future posts on this topic.
# Posted By Jeff Caldwell | 9/7/06 3:00 PM
Thanks Darren and Jeff. Darren's response (as someone from Integral) is a great testament to how much they do want to make sure all users are satisfied. I think most will over time come to really appreciate that. And Jeff, I appreciate your perspective and of course agree.
I think something that might help is a Captivate or Breeze presentation showing someone actually using the debugger to solve real problems. Lay out 4 or 5 common issues and then walk through how using the debugger helps you solve them.

I'm also one of the people who got the debugger working in CF Studio only to try it and go "I just don't see what the big deal is". Since most CF'ers have never had access to a debugger, seeing someone using it might be the catalyst to get people thinking. Just my 2 cents.
Hey, Brian, if you missed it, I pointed out above they do offer Captivate videos. Now, maybe you don't mean just "showing it being used" but more specifically solving specific problems. I will be doing that, but until then, I offered a link in the entry above to their current videos.

Further, I do plan to record my presentation where I do demo it. As you say, I can see when I present step debugging to people that for many, it's a total eye opener.
Yes, I did report the problem to Intergral (I feel like saying "of course") and they have not been able to reproduce it. I promised them that when I am not quite as buried in work as I am right now, I'll rebuild my Eclipse environment from scratch and give it another ago (despite the fact I don't think step debuggers are useful!).

FWIW, and in response to several people commenting here, I thought the installation instructions were crystal clear and pretty simple for something as "intrusive" as FusionDebug so kudos to Intergral for that.

In response to Brandon: I find Eclipse to be rock solid and this is only the second time - in several years of use - that a plugin has caused me problems of any note. And that includes when I was actually building some plugins of my (and running builds of CFEclipse from source using the latest code from the repository!).

Since my comment was a bit of a drive-by shooting, I should probably elaborate on my "disdain" for step debuggers.

If you have no idea where in your code a bug is, you're going to have to step through a *lot* of code and watch pretty much every variable in order to track it down. That just isn't feasible for large, complex systems. On the other hand, if you have some idea of where the bug is, you can zero in on it very quickly with a few judicious cflog or cfdump tags - even in a large system. And, of course, if you have a small system then you don't have much code to either step through or fill with cflog / cfdump tags (but if you have a small system, you have less code to find bugs in anyway!).

What I think we really need as a community is more information about how to become better at debugging our code - without that basic understanding, no amount of tools can really help.
I'd like to +1 Sean's last paragraph. Debugging is something that you don't see a lot of articles on it. You made the point about what a developer would do if they weren't sure where the bug is - and that hunting itself can be a bit an art to itself.
Goodness, Sean. How can you call it "intrusive". That just seems so unfair. I know I've not yet explained to the uninformed here the details of what it takes but I did say it was just a single line change to the JVM config. That's hardly intrusive. :-)

Had they somehow made you put in new JARs that overrode those in CF or something more heavyweight, one might agree, but this seems remarkably lightweight and decidedly unobtrusive--especially in that it came from a company that did it all on their own.

As for the experience of Eclipse plug-ins and their corrupting them, besides Brandon's experience I will add that just today I heard this week's ColdFusion Podcast where Bryan and Michael were talking about how the use of the Subclipse plugin had corrupted their Eclipse environment, so it's clearly something that can happen. The FD one seems pretty simple, so it would seem this was indeed unique (and Darren's own confirmation based on all the downloads so far seems to confirm that.)

As for the initial comment being something of a "drive-by shooting", I'll concur that it's what it felt like. :-) Thanks for the clarification of your perspective. I have some thoughts of my own to help justify where I think a debugger can help. I hope that discussion from that or this (or others' entries) may help spur a discussion to help everyone learn what makes the most sense for them. Until then, I hope folks will have an open mind.
For what it's worth, I run MyEclipse (a massive collection of plugins and utilities), Subclipse, TeamTask, CFEclipse, and more. I haven't had any problems with things corrupting on me.

Just to be sure, though, I do copy my entire eclipse-installations, eclipse-workspaces, and eclipse-extensions directories in their entirety to backup folders on a semi-regular basis. This way, just in case something goes horribly wrong, I can get back to a known point without the hassle of rebuilding everything.
I have been using FusionDebug for a couple of months now and think there are plenty of occasions when it's useful. I agree it's not always appropriate to use all the time; but any tool that makes my life easier is definitely worth the money.
Sure when you're starting a project maybe you don't need to use it all the time; but as someone else (sorry too lazy to find who it was!) said it's great for seeing exactly what's going on and where you've accidentally set the wrong variable etc...

As a senior developer I also find it very useful for training others in what CF is actually doing. Especially when developers have come from a Visual Studio or other step-through debugger type environment. I find it's a lot easier to show a new developer what's happening line by line with the ability to show variable contents etc as it's being executed rather than explaining final outputs.
Sure there's the "why don't you just put cfdump/cfoutput/cfabort all through your code?" question but who wants to do that when there's a tool thats right there in your IDE?

Just my 2p... Comments appreciated
# Posted By David Stockton | 9/8/06 6:25 AM
The comments here are incredibly discouraging. This tool desrves the support of the community most of whom do not code "large, complex systems" and haven't been programming in Pascal since the 80's.

That was more than a drive by shooting... more like an IED. I sure hope that wasn't the "Kiss of Death" for Fusion Debug.
# Posted By Jay Greer | 9/8/06 12:29 PM
To be fair - the community needs to be mature enough to say, "One person says this is a bad idea, one does not. Let me do my own research to see what makes sense for me." Sean gave his opinion. Charlie is sharing his thoughs. Anyone who says, "Sean says X so I'mjust leaving" is not doing their own part to increase their own knowledge. I'd say the same for anyone who said, "Ray says X...". None of us here are perfect, and we certainly do not all agree. Thats the nice thing about blogs - you get both the author's opinion, and the audience as well.
Yeah, I got pretty tired of (some) people slavishly following whatever I recommended (and copying my examples line by line without understanding them!) that I've tended to do two things:

1) Simply stop offering certain types of code example and advice.

2) Being more controversial.

That's led to my reputation for saying "It depends!" - I'm just trying to get people to think for themselves a bit more. I don't want anyone to just slavishly follow anyone's recommendations...

When I get time (hah!) I'll rebuild my Eclipse environment from scratch and try installing FusionDebug again and if I can get it working successfully I'll write about it (which was the whole point of trying to install it in the first place!).

Clearly, from the comments here, some people *do* have problems with Eclipse and plugins and *are* concerned about modifying JVM configuration. I hope some people *do* find FusionDebug both easy to install and useful - the Intergral team have clearly put a lot of work into the product - but at the same time, I also overheard negative conversations about the preview at CFUNITED so it really is a case of caveat emptor.
Sean, as Billy Joel said, "don't go changin'...[we] love you just the way you are". :-) There's a place in the community for all the different personalities and perspectives out there.

But I will say I do favor "sharing" over "scaring". :-) In that regard, I hope any who had such negative conversations have taken their issues to the vendor, rather than just keep their experiences to themselves (as I said in the first comment above). Since Intergral is reporting that only one such occurrence has happened, it's imperative that any with such experiences report them so they can be dealt with, rather than speculated or rumoured upon.

And as for saying "it depends", I'm totally with you. I'm not at all saying that everyone should be using the tool, but I do think everyone should give it more serious thought and attention that it seems most have (judging by the blogosphere and [lack of] mailing list traffic I've seen). I certainly don't expect anyone to "slavishly follow" that recommendation. I'm just trying to sincerely motivate them. That's all. :-)
I didn't find FusionDebug any more "intrusive" than other useful CF add-on tools like SeeFusion 4 that both Sean and Charlie have praised (I hope that's an ok word) recently. In fact the JVM configuration for SeeFusion is exactly the same as for FusionDebug. Just a tip for SeeFusion 4 users; if you've configured the JVM already you can just start using FusionDebug after it's installed in Eclipse by connecting to the default port 28999, and in my opinion it’s well worth a look!
# Posted By Jason Powers | 9/9/06 10:53 AM
Great points, Jason. Thanks for sharing.
I want to go back to my original comment, although for some reason I can't find it.
If you're lucky enough to have a veteran ColdFusion developer introduce you to cf, then I can imagine a scenario where the developer would install Eclipse on your computer, install cfEclipse, install Fusiondebug and then say "OK, now let's start learning ColdFusion."
But if you are like most people - on your own (and most learning is done on your own), then the scenario goes quite different. The first thing you do is start playing with the tags.
"Now let's see:
cfset x=1, check.
cfoutput x, does it equal 1? check.
cfinput X, does it equal 1? No. Why not?"

It would be nice to have an editor that showed the difference between variables.X and FORM.X, but I don't think the first thing a cfPadawan will do is download a plug-in for an open-source editor that isn't mentioned in any of the adobe documentation.
Especially when they're struggling with why "LET X=1" isn't working.
Phillip, your other comment wasn't here but in the "part 2" article. That said, if you're lamenting that a tool not made by Adobe will be less readily found by most folks, that's a fair point. It's also why I'm doing what I can to help spread awareness.

If instead your indirect point is more to wonder whether and why Adobe does not offer debugging, well, it's not a new discussion. Debugging was dropped in CFMX because the sense then was that there wasn't enough interest. I argued that it was more just that people didn't know it was supported by CF Studio in CF4 and 5, but the decision was made.

Given now the rather tepid response to FusionDebug so far (and the clear antagonistic sentiment of some toward debugging in general), I don't think we should hold our breath that Adobe will come out with one.

Further, if the tool does the job well and couldn't be much improved (and Intergral are already working on their own improvements), and especially if Adobe didn't also give away any debugger they'd make, there just seems little motivation for them to bother.

But we can't know how the future will unfold. Until and unless Adobe does do such a debugger, let's simply celebrate, enjoy, and benefit from the fact that we do now have FusionDebug. :-)
@Jason, re: SeeFusion - the only mention I have ever made of SeeFusion was in relation to HostMySite implementing it to monitor server instances to improve their uptime (by shutting down 'bad' processes). I have not installed SeeFusion and beyond seeing a demo of it, have no opinion about it.

I just wanted to correct the record to say I have *not* praised SeeFusion!
An update: I have re-installed FusionDebug without it damaging Eclipse but I deliberately removed the Windows JRE it installs, before I let Eclipse restart the workspace. That makes me wonder if the Windows JRE was the problem (I'm on an Intel Mac).

However, FusionDebug still won't connect to the localhost JVM :(

I'm in communication with the Intergral support folks...
Glad to hear it's moving in the right direction. I forgot to consider that you're on a Mac (and the Intel one, at that), so clearly it offers its own unique experience. I did just see something today in some list where the FD folks pointed out a generic issue with Eclipse debugging on the mac, and they pointed the gent to an appropriate Eclipse article for more. I'm sure it if't appropriate to Sean's situation, they'll be sharing it with him. Thanks for the update, and let us know if it gets resolved.
Copyright ©2023 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting