Migrating Legacy CF9/Coldbox 2.x App to Lucee/Coldbox5

Communities ColdBox HMVC
1

Hi Everyone.

I’m attempting to “update” an older CF application that is mostly in ColdBox.
After working with ColdBox a little bit … I can’t believe I did CF programming without it. Ever.

I’m at the point of still reading and learning so I can know how to ask the questions, such that I make it possible to get help.
Some of the unknowns for me are dealing with how all this stuff gets set up. Once I’m in an editor and looking at CF code … I’m fine.

The application’s basic setup is currently:

CF9 Enterprise running on CentOS -Tomcat7 - JRE1.8
(I think this means CF is running as a J2EE container?)

2

After working with ColdBox a little bit … I can’t believe I did CF programming without it. Ever.

Excellent, your conversion to the dark side is nearly complete.

CF9 Enterprise running on CentOS -Tomcat7 - JRE1.8
(I think this means CF is running as a J2EE container?)

Close. CF Always runs in a servlet container. What that does mean is that CF was installed using the “JRE installation” as Adobe calls it.

/usr/local/Cellar/tomcat@7/7.0.82/libexec/webapps/ROOT/Application.cfc (Permission denied)

The permissions denied is probably just a permissions issue with the user you’re running box as and that user not having write access to that folder. You can run box as root with sudo but just keep in mind that will usually create a second installation of CommandBox under the root users’ home. On a related note, I hate sudo about as much as I hate the stupid “run as administrator” nonsense in Windows.

My first goat is to get Lucee5 set up on my dev machine

Regarding your servers, you’re putting way way too much effort into this. You don’t need Tomcat and you don’t need to manually install Lucee. CommandBox is all you need!

cd myNewSite --cd
coldbox create app
server start cfengine=lucee@5

That will give you a running Lucee 5 server with a ColdBox sample app and it’s like 20 seconds worth of effort. You will find this to be infittley less work than screwing around with Tomcat. And when you’re ready, read up on server.json and CFConfig. You’ll never install a CF engine again.
https://commandbox.ortusbooks.com/embedded-server/configuring-your-server

https://cfconfig.ortusbooks.com/introduction/getting-started-guide

3
  • There is no dark side of the moon really. Matter of fact it’s all dark."

Thanks for the quick response. I was just about ask about the next error I got after I copied from my lovely Coldbox Legacy App Demo -
But rather than do that I’ll take your advice and get things set up as you suggest. CommandBox and ColdBopx are so awesome I can’t quite wrap my mind all the details.
I used to be hooked on phonics … but now I’m hooked on ColdBox! thanks fellas

4

Regarding your servers, you’re putting way way too much effort into this. You don’t need Tomcat and you don’t need to manually install Lucee. CommandBox is all you need!

  • The reason why I tried to do the manual installation, is cause I needed to:
  1. be able to use tomcat7 for the install (because thats what we’re using on the production servers)
  2. be able to “deploy” the app through a custom deployment system written in perl, which I don’t understand.
  3. know that while I can use commandbox to create an app skeleton - don’t really understand how or if I could use it to “deploy” our legacy app.

Part of this excercise is a proof of concept to see if the codebase can be modified to run on Lucee and a newer version of Coldbox.
I refuse to believe its not possible - even though some CF-haters at my work say its not.

“fearlessly - the idiot faced the crowd” is my motto … I’m sticking to it.

5

be able to use tomcat7 for the install

Does your app actually require Tomcat? That seems unlikely unless you’re tying into some very specific Tomcat features, settings, or servlet filters, etc. Tomcat is just one of many servlet containers, but 99% of CF apps don’t really know or care what servlet container they’ve been deployed on. CommandBox uses JBoss Undertow (part of their Wildfly server) which is smaller and faster than Tomcat and should be an invisible replacement. This is just local development we’re talking about here. You can still use whatever you want for production, but if you’re just spinning up a server to test, I wouldn’t worry about that level of details.

be able to “deploy” the app through a custom deployment system written in perl

Sounds horrible :slight_smile: I would suggest you point your dev ops people at the Ortus Docker Images. They are powered by CommandBox are are much much more inline with industry standards when it comes to deployments. But regardless of how you deploy your code to stage/prod/etc it shouldn’t preclude the possibility of spinning up a Lucee 5 server however you see fit on your local machine for testing. The CFML code, after all, most likely doesn’t really know or care what it’s running on.

know that while I can use commandbox to create an app skeleton - don’t really understand how or if I could use it to “deploy” our legacy app.

The CommandBox scaffolding commands are nothing more than a giant glorified “Right Click > New > Text Document”. They just dump files and folders into a directory for you to make your life easy. You deploy these files and folders to another server however you see fit. Note the CLI scaffolding commands are a separate beast from running a server with CommandBox. You can use CommandBox to scaffold out files and apps and not use CommandBox to start your server or vice versa. Many people use CommandBox for easy development and then fall back on all sorts of custom legacy deployment methods for their actual production servers.

Part of this excercise is a proof of concept to see if the codebase can be modified to run on Lucee and a newer version of Coldbox.
I refuse to believe its not possible - even though some CF-haters at my work say its not.

As someone who’s converted quite a number of sites from Adobe CF to Lucee as well as performed a great number of ColdBox upgrades, I don’t see why it wouldn’t be possible. Depending on the size of the app, there might be some work involved just to update everything, but it’s all just code at the end of the day :slight_smile: You might want to tackle one of those items at a time. For instance, get the current app running on Lucee 5. Usually, the older the app, the less work it will take since the core CFML tags are pretty compatible. Then once you’ve done that review the upgrade guides for ColdBox and start on that.
https://coldbox.ortusbooks.com/intro/introduction

The core ColdBox conventions have changed very little but other stuff like wirebox, cachebox, logbox, etc have changed a fair amount. Depending on your application, you may not be using any of that anyway which may make your job easier.

If you need help in this venture, Ortus always has paid support services and we specialize in helping people upgrade stuff :slight_smile:

6

be able to use tomcat7 for the install

Does your app actually require Tomcat?

  • Probably not. The CF part of this is only part of the application. A part that is being rewritten entirely to not use CF. (LOL!)
    The rest of the stuff is in Java and Backbone. I’m not part of that team - since I’m “only” a CF contractor, and “REAL” programmers don’t use CF. :wink:
    My wanting to use Tomcat was purely to see if Lucee can run on it (which it can).

That seems unlikely unless you’re tying into some very specific Tomcat features, settings, or servlet filters, etc. Tomcat is just one of many servlet containers, but 99% of CF apps don’t really know or care what servlet container they’ve been deployed on. CommandBox uses JBoss Undertow (part of their Wildfly server) which is smaller and faster than Tomcat and should be an invisible replacement. This is just local development we’re talking about here. You can still use whatever you want for production, but if you’re just spinning up a server to test, I wouldn’t worry about that level of details.

  • I’m taking that route now. I’ll split my work into a few parts- rather than do it all at once. I just didn’t want to “upgrade” our coldBox application to 5 → only to find that it wouldn’t run on whatever constraints I’m under.
    (ie using tomcat7, being on centOS, etc)

be able to “deploy” the app through a custom deployment system written in perl

Sounds horrible :slight_smile:

You said it, brother. It’s unlike any other deployment system I’ve used. Most of my experience is developing on 1 - 3 CF servers, and just pushing the code.
This is not the case here.

I would suggest you point your dev ops people at the Ortus Docker Images. They are powered by CommandBox are are much much more inline with industry standards when it comes to deployments. But regardless of how you deploy your code to stage/prod/etc it shouldn’t preclude the possibility of spinning up a Lucee 5 server however you see fit on your local machine for testing. The CFML code, after all, most likely doesn’t really know or care what it’s running on

  • Right. I started setting up a local environment after waiting a stupid amount of time for devOps to get me an empty tomcat container.
    I decided I would handle the application CB upgrade/lucee test locally - and if that worked … move ahead.

know that while I can use commandbox to create an app skeleton - don’t really understand how or if I could use it to “deploy” our legacy app.

The CommandBox scaffolding commands are nothing more than a giant glorified “Right Click > New > Text Document”. They just dump files and folders into a directory for you to make your life easy. You deploy these files and folders to another server however you see fit. Note the CLI scaffolding commands are a separate beast from running a server with CommandBox. You can use CommandBox to scaffold out files and apps and not use CommandBox to start your server or vice versa. Many people use CommandBox for easy development and then fall back on all sorts of custom legacy deployment methods for their actual production servers.

  • I’d like to use commandbox wherever possible, as it seems to make things easy.

Part of this excercise is a proof of concept to see if the codebase can be modified to run on Lucee and a newer version of Coldbox.
I refuse to believe its not possible - even though some CF-haters at my work say its not.

As someone who’s converted quite a number of sites from Adobe CF to Lucee as well as performed a great number of ColdBox upgrades, I don’t see why it wouldn’t be possible. Depending on the size of the app, there might be some work involved just to update everything, but it’s all just code at the end of the day :slight_smile: You might want to tackle one of those items at a time. For instance, get the current app running on Lucee 5. Usually, the older the app, the less work it will take since the core CFML tags are pretty compatible. Then once you’ve done that review the upgrade guides for ColdBox and start on that.
https://coldbox.ortusbooks.com/intro/introduction

The core ColdBox conventions have changed very little but other stuff like wirebox, cachebox, logbox, etc have changed a fair amount. Depending on your application, you may not be using any of that anyway which may make your job easier.

  • Most of the legacy code is pretty basic CF/coldbox. I don’t think wirebox, cachebox, or logbox are being used.
    The main issue I have is that I haven’t found current documentation on how to upgrade from CB 2.x to 5.x.
    Some of the Ortus links I’ve found posted are dead links.

If you need help in this venture, Ortus always has paid support services and we specialize in helping people upgrade stuff :slight_smile:

Well I’m sure I will … but I don’t write the checks. If I did … I wouldn’t blink.
Before I arrived - the other “real programmers” weren’t even sure if it was possible to upgrade from CF9 to CF2016.
Nor did they have any idea that Lucee existed. For us - its not just one CF license. We’ve got 100 of them that they are “needing to replace”
Personally, I think if I can get the application to work in Lucee with a new version of CB → both Ortus and myself should get some love.
Namely - cheddar. and I ain’t talkin bout cheese.

7

I do know however that they will need to $$ that PDFFORM extension in order to use Lucee. (Ortus PDF Extension)
(It’s the only “unsupported” tag I’ve found in the codebase so far)
Once I get a little more footing on this upgrade process - it will be much easier for me to convince the managers to kick down $$ to Ortus.
I’m guessing paying out a bit to rework the application, getting support as necessary from Ortus - is a fraction of the cost of buying 100 CF licenses.

8

As someone who’s converted quite a number of sites from Adobe CF to Lucee as well as performed a great number of ColdBox upgrades, I don’t see why it wouldn’t be possible. Depending on the size of the app, there might be some work involved just to update everything, but it’s all just code at the end of the day :slight_smile: You might want to tackle one of those items at a time. For instance, get the current app running on Lucee 5. Usually, the older the app, the less work it will take since the core CFML tags are pretty compatible. Then once you’ve done that review the upgrade guides for ColdBox and start on that.

Is there a working link for upgrading? I notice there are quite a few links back to Ortus that are no longer working

https://coldbox.ortusbooks.com/full/introduction/upgrading-to-coldbox-5

https://coldbox.ortusbooks.com/intro/introduction

  • I’ll check that one out.

Thanks again for everything.

9

Sorry about the dead links. There’s two factors at play. The first is that we retired out old wiki site several years ago after the 3.0 release and it seems some of the really old upgrade guides never made it over to the new docs. I’m not sure if that was an oversight or because we figured noone would need them any longer. Here is a backup of the what’s new in 3.0.0 from the wayback machine:
https://web.archive.org/web/20160403145224/http://wiki.coldbox.org/wiki/WhatsNew:3.0.0.cfm

The second thing working against us is that GitBook did a massive upgrade to their site recenlty and it changed all our docs links which kind of sucked. You can find most all the pages by using the search feature and if you point out broken links anywhere I have the power to edit, I’ll update them. Here’s the proper link to upgrading to ColdBox 5
https://coldbox.ortusbooks.com/intro/introduction/upgrading-to-coldbox-5

in Java and Backbone

Wow, that sounds like such a waste of money. Java is one of the least productive languages I can think of to write a web app in. The JVM is defo where it’s at, but that’s where dynamic, rapid dev langs like CFML kick java’s butt. (You can tell your “real” devs that!) I’d like to show them some of our ColdBox-powered Vue.js apps.

getting support as necessary from Ortus - is a fraction of the cost of buying 100 CF licenses.

Heck, for the cost of a few CF licenses, you guys could become full fledge Lucee members for crying out loud. That would give you direct access to the devs, priority bug fixes, and an actual say in the direction of the product. Try getting that from Adobe or Oracle. (Ortus is a Lucee member)

run on whatever constraints I’m under. (ie using tomcat7, being on centOS, etc)

The only thing in that list that bothers me is Linux and that’s only if you’re moving from Windows/IIS due to case sensitivity and backwards slashes. Nothing that can’t be fixed, of course. I’ve done a lot of upgrades from Windows/IIS/ACF to Linux/Nginx/Lucee for clients and case sensitivity tends to get in the way. We’ve helped some very large companies execute the movement of hundreds of legacy apps over to Lucee/Linux stacks before.

Nor did they have any idea that Lucee existed. For us - its not just one CF license. We’ve got 100 of them that they are “needing to replace”

I’d love to present to your company and I mean that seriously (and not just because I have services/products they might want to buy). Just as a CF enthusiast who really really hates to see people leave CFML, especially for crap reasons, I’d happily meet with developers or even brass at your place to talk about the modern tooling available in CF. I’ve done this before (presenting remotely) at places that were entrenched in legacy-land CF just to get them up to speed on some of the things out there they didn’t even know existed in this space. Let me know for realz if you can get any of your “real” developers over there to sit down for an hour and learn how we kick butt and take names with CFML in 2018.

10

Thanks very much for updated l links.
I’m totally with you on all your points below. I was already thinking the same things.
Once I have the app running on my machine on the new version of CB … it’ll be pretty easy to get their attention. :wink:
Regardless - I’ve been a CF enthusiast for a while. Working with Ortus tools makes it even more of a pleasure.