Working with old frameworks – Fusebox 4 & 5

So – I am responsible for maintaining a legacy application that runs on ColdFusion with Fusebox 4. My Team Lead wanted to move the application to Fusebox 5 – to bring us up to the latest release of the framework.

Problem #1 – Fusebox isn’t being actively supported anymore.

Solution # 1 – After some hunting through Facebook groups and Slack channels – I was reminded of “The Wayback Machine” – a website that archives other websites over time. After finding the LAST release of the “” websites – I downloaded the latest Fusebox core files. While I was doing that – I found a GitHub repo that actually had later files (after the demise of So… I grabbed those core files instead.

I set up a new ColdFusion site for testing. Then, I installed the Fusebox core files – and their “skeleton” app (so I could re-familiarize myself with the framework that I haven’t worked with in YEARS).

Problem #2 – Fusebox threw an error. It was telling me it couldn’t find one of the primary files for the app (fusebox.xml). The thing is – the file was there – exactly where it was supposed to be. UGH!

Solution #2 – Pulling my hair out! OK – No… My hair’s too short to pull out. So – back to Google groups, Facebook groups, and the Wayback Machine. All to no avail. At that point I went back to GitHub and wandered through some of the old “issues” for Fusebox. There, I found an “issue” that was “similar”. It appears someone tried to use Fusebox 5 with Lucee (an Open Source ColdFusion engine) and ran into a problem with certain function names. It seems that Lucee AND Fusebox both have a function named “getCanonicalPath” – and they both return DIFFERENT results. So – OF COURSE – the Lucee function took precedence – and gave Fusebox a result that didn’t work for Fusebox’s needs.

After a little research into the “guts” of ColdFusion – I found that the version we use (Adobe ColdFusion 2018) – ALSO has the EXACT same “problem”. So – I “branched” the Fusebox 5 Github Repo and changed the name of the Fusebox function from “getCanonicalPath” (the offending function name) to “getFBCanonicalPath” – and then renamed all the calls for that function in the Fusebox branch.

After deploying my NEW Fusebox branch to the test application site – VOILA! The app performs as expected.

This entry was posted in ColdFusion, Fusebox, Legacy, Programming and tagged , , .


  1. Brad Zinn May 3, 2019 at 12:45 pm #

    Thank you Sid for your solution!

    I was having having the same issue. I just migrated a few fusebox 5 apps to our new CF 2018 server from CF 10. Kept getting an error that my fusebox.xml file was missing when I could see it was obviously there. So, I went into the Fusebox framework and replaced the offending function with the new one and BINGO… worked like a charm.

    Many Thanks for your efforts and saving me hours of work.

  2. sidwing May 3, 2019 at 5:51 pm #

    Glad it was helpful!

  3. Peter May 30, 2019 at 4:09 am #

    How very obscure! Yep, just saved me, so thank you VERY much.

  4. Christian June 13, 2019 at 6:42 am #

    What a luck I found your post. We got this error today morning in some FB5 applications after an update to CF2018. Because of your instructions, the problem was solved quickly.

    Many thanks for sharing this information!

    • sidwing June 13, 2019 at 8:06 am #

      Christian – Glad it was helpful!

  5. Dörte November 14, 2019 at 1:36 am #

    I am happy that I found your post! I had the same problem with a fusebox 5.5 application on checking the update from ColdFusion 10 to 2018. Many thanks!

  6. Jim December 10, 2019 at 3:50 pm #

    Thanks for this! Saved me.

Post a Comment

Your email is never published nor shared. Required fields are marked *