For anyone who’s been kept away from CommandBox because you have a ton of virtual hosts and don’t want to have just as many separate CommandBox servers, this feature is for you. Please help me test it before it releases!
Traditional CommandBox servers have only a single web root, so if you run an Saas setup where you have 200 separate web roots in IIS, CommandBox wasn’t a very tenable solution for you since it would be a waste of resources to start 200 servers. With the addition of support for multiple contexts, you can now stick a single CommandBox instance behind
Nginx (with some manual headers added)
with as many virtual hosts as you like defined in the web servers. With the flick of a switch in CommandBox, it will create new contexts, each with their own web root, on-demand.
server set modCFML.enable=true
# Set in BonCode or mod_cfml config
server set modCFML.sharedKey=myKey
This new feature does basically what the mod_cfml valve for Tomcat does, but in CommandBox/Undertow. It also works with Lucee Server and Adobe ColdFusion. The only real drawback right now is that on Lucee, CFConfig will import your config into the server context, but since the web-contexts will be created on-the-fly after the server is started, they will not have any config imported into them since they’re created after-the-fact. This only applies to servers with modCFML.enable set to true.
Great question. Right now the answer for Adobe is yes only because there’s only a single context!! The answer for Lucee is… no CFConfig will only apply to the main server context,. which the web contexts inherit from.
There is basically a pretty large decoupling between the CFML bits of CommandBox which power the CLI, announce the server start interception points, and load the config preemptively into the folders where the server is about to start in and the Java-based Runwar tool that actually powers the server once it’s running. When CommandBox starts a server, it fires off a new Java process with a bunch of JVM args that control the server, and then the CLI bows out of the picture and can be shut down, heck even uninstalled at that point (see our finalized Docker images for an example where the server can be still running with CommandBox and it’s CFConfig module fully uninstalled).
The trick is that
CommandBox has no idea what contexts will be created ahead of time (and if you had to tell it, it would largely defeat the purpose of mod_cfml)
All new contexts are added at run-time minutes, hours, maybe days after the server has started.
Now, this doesn’t mean it isn’t possible if we’re willing to make some assumptions and invent some new conventions-- I just haven’t worked on it yet. What I’d need to do is provide some “hook” inside runwar that can be used to execute something arbitrary any time a new context deploys (which is still tricky since Lucee still has control over WHERE the new contexts will go and Runwar can’t always detect that. I solve this in a non-mod_cfml mode by simply forcing Lucee’s web context location so I know ahead of time, but that doesn’t work as well when there can be an unlimited number of them) So anyway, if I can build a hook into Runwar that fires off some CommandBox command when a new context deploys (assuming CommandBox is available, etc, etc) then I can probably create some convention such as looking for a CFConfig file in the web root and importing it on-the-fly. I’ve put some thought into it, I just haven’t had a chance to try it and I’m not entirely sure how well it will work, lol