I recently inherited a Coldbox application that was developed many years ago and have been tasked with upgrading it to the most current version. It has never been upgraded and it is honestly a miracle that it is still running. It is a very large data entry application with hundreds of handlers, models, and views. It uses plugins (now deprecated) extensively as well.
I downloaded Version 7, got a sample application up and running, and am trying to figure out if it is better for me to upgrade first to Version 4 and then upgrade to each version iteratively or to tackle upgrading directly from Version 3 (beta) to Version 7. The sample code for Version 7 apps looks pretty drastically different than the code in the application. Am I going to have to rewrite the entire thing?
Does anyone out there have any guidance on the best course of action for this massive undertaking?
*It is also worth mentioning that using CommandBox isn’t an option. I currently don’t even have rights to restart ColdFusion on my local development server. I’ve been working on getting that approved for three months so getting them to approve an application that isn’t already in their list of allowed applications is going to be next to impossible. Thank you!
If you go to https://coldbox.ortusbooks.com/ you can select the versions. The earliest version there is 4, but you can probably use that to get started by reading the “What’s new” guides in the “Introduction” sections.
Start with 4, apply any refactoring, then 5, then 6, etc. I can’t find any “What’s new in Coldbox 3” posts out there, but @lmajano may have that one around somewhere on his local hard drive. The Trac site we used to keep all of those is no longer up and running, in favor of Ortus Books.
1 Like
@gskopinski Just post here and we can help as much as needed. However, please note that as part of our Professional Services, we can also assist in this.
1 Like
The earliest release I’m seeing here is Version 5: Releases · ColdBox/coldbox-platform · GitHub
I’m assuming I can get it through CommandBox, but again, not an option.
I appreciate your help so much!
I wouldn’t even bother trying to verify the refactoring on previous releases. Just work through the refactoring, step-by-step, until you get to Coldbox v7 and all of the current versions of the modules.
Then you can start it up and test. A majority of your code will probably require little to no refactoring. The places where you will probably see the most refactoring will be in the handlers, interceptors, and views - when using built in supertype methods or calling methods from coldbox/wirebox.
May we ask what’s the reason of not allowing CommandBox?
@jclausen, When you say refactoring step-by-step, do you mean, reading the release notes and updating the code without verifying that it ever properly upgrades to the next version before moving onto to the next version? That seems more complicated and prone to problems than just throwing v7 in there and fixing errors one-by-one until it works? 91 handlers, 536 model files, and 672 views is a lot to make massive changes to and just assume they are right without any testing.
@lmajano, I’m a contractor for the government and my PC is locked down to an unreasonable level. I cannot install anything without approval and they approve basically nothing and absolutely nothing that isn’t in already in their list of supported applications. CommandBox isn’t. I currently have to restart my entire PC to restart CF because I don’t have rights to start/stop services. Frustrating to be sure. I wish the contract allowed to pay you guys to do this but I’m 99.9999% sure they won’t.
@gskopinski : We work with a number of government clients and CommandBox is supported and whitelisted in DADMS as well as non-DoD FedGov systems.
Yes, I mean refactoring/updating code between each phase without verification - saving the verification until you have completed all of the upgrade iterations. There will be some issues which arise in final QA, but you can deal with them all then - rather than potentially spending time on fixing things that will need to be changed/re-fixed in the next update iteration.
I can tell you from experience, having done this kind of update refactoring many times that it is much more efficient this way. Scary, possibly, but make a commit at each update iteration so you can track the changes in each phase.
1 Like
I agree with what Jon said. We use CommandBox in many DoD Gov projects without issue. CommandBox can be run without being installed, and even executed off a thumb drive so it’s never on the machine. You also don’t need to touch Windows services at all in CommandBox so I’m not even sure what you mean there.
1 Like
Good to know. I will look at it further. I went into the list of supported Apps to try to request that they install it and it wasn’t there so I made an assumption. If it doesn’t need to be installed, I might be able to use it. I’ll look closer at it on Monday. Maybe it will allow me to start/stop CF 
Thanks for the guidance! I will go the route you suggested - that’s why I asked before I dug in!
After estimating the effort required for this upgrade, as well as the agency’s overall strategy to phase out ColdFusion entirely by 2027, I’m questioning if either of you have a good grasp on the risk of continuing to run such an old version of Coldbox (we are actually on 3.0, not 2.0). From what I’ve read, the upgrade to CF2018 caused some issues with the way java objects are instantiated and Adobe had to patch it so it seems like Adobe is committed to supporting it. The driving force for this upgrade was that we tried to upgrade to Java 17_0_7 to Java 11_0-19 and it caused issues with Coldbox, requiring us to revert back (which seems to be a universal problem with Java 17 and CF2021).
Assuming I can get our current application to run on the beta of CF2023 (we are currently on CF2021), is it unreasonable to hope that the application will continue to run for the next, say, two to three years without updating Coldbox? I appreciate your feed back so much. We are certainly at a crossing point here after this app being neglected for so many years.
If feels like you are asking us to sign off on not updating your application until 2027 - which is a really long ways away. I am not aware of any known vulnerabilities or performance issues in Coldbox 3. That said, should any arise, it is so far out of support that you would be on your own to address and fix them.
Coldbox 7 is much more powerful and more performant. IMHO the small amounts of progressive refactoring you would need to do, in order to move your application in to the most recent version of the framework, would be worth it. That’s your call, however.
The only CFML engines that run on Java 17 are Lucee 5.4 and Adobe Coldfusion 2023. Even then, you need to add opens to allow for reflection on Java 17 because it’s disabled by default. @bdw429s has automatically added all of those that are required to run Coldbox in CommandBox v5.9.0 and above. When you start a server using CommandBox versions above that, you will see all of those opens passed as JVM arguments. If you wish to run your server on anything other than CommandBox, and use Java 17, you will need to add those as well.
1 Like
Agreed, 2027 is a very long way away and I can’t in good conscience recommend staying on outdated frameworks. If you’re concerned with the level of effort to update your app, consider hiring Ortus to help do it for you. We have consulting plans and do this sort of thing for customers all the time. I don’t know the size or complexity of your app, but I’m fairly sure we could get you updated in not much time, or at least walk beside you in the process.
In unrelated news, why is your org wanting to move away from ColdFusion? Are they open to conversation about why that may be a very expensive and boneheaded decision
2 Likes
@jclausen and @bdw429s, I appreciate your time and comments. The application is quite large - 91 handlers, 531 models, 673 views. It uses plugins extensively, as well as spry. From what I understand, most of the objects were generated with Coldspring. The code looks pretty drastically different from the Coldbox 7.0 test app that I got up and running.
At this point, I’m just trying to find a balance between where the agency is headed and where we currently are. Until the “plan to be off of CF by 2027” guideline came out, I was planning on upgrading Coldbox because I definitely know that continuing to run an outdated version is a huge risk. I know that something needs to be done now and in no way do I plan to push it off until 2027. If we decide to rewrite now, I’d put the hours it would take me to upgrade into the rewrite rather than the upgrade to Coldbox 7.
I did mention the possibility of hiring Ortus should we get into a bad situation between now and when we either get it upgraded or rewritten so I’m absolutely thankful that is an option!