I think it’s also reasonable to expect an artifact not to have to be build for deployment to a specific environment
That’s a great goal, but it’s not always possible. For instance, I deploy tests to my test env, but not on production. I also apply different security locks downs on production. Many changes such as passwords or different DB settings are possible via JVM args or env vars however.
. It sounds like your suggesting that there isn’t, in fact, a way to deploy lucee applications without CommandBox.
That is not true, there are many ways to deploy Lucee without CommandBox. CommandBox is simply my favorite since it’s the most portable, most configurable, and most extensible. Full disclosure, I’m part of the CommandBox project. If you’re open to rethinking your deploys to a method that doesn’t involve war deploys on an existing servlet, I think it’s worth considering as we’ve already solved most all of these issues there.
I was referring to the statement that CFConfig is “an underlying service layer”
There are two CFConfig projects. One that is just the service layer, and another which is a CLI tool (a module for CommmandBox). The latter has no dependencies outside of the box binary being present on the machine. Once the module is installed, it generates commands you can run to manage config on disk.
First reason is because I want to have an application artifact that is not built for a specific environment. Second reason is because the location that the configuration be injected (the lucee config) may not be present until load. (Lucee sees the web admin files are missing and creates them; this includes the config file) Yes, CFConfig is designed specifically to address it, and it would be a great tool. But I need to build it into my artifact, to be able to load on startup and apply the config.
Right, so it’s hard to reply to that paragraph since I think there’s at least 3 different options being discussed here simultaneously and I’m not sure which comments of yours go with which approach.
- Pre build the war with all config so it’s ready to deploy
- Build a war and have a deploy-time process that modifies config on the fly
- Scrap the whole WAR idea and move to a server solution like CommandBox
And of course, other server ideas we’re not discussing include a “typical” installation of Lucee which embeds Tomcat, but I’m assuming you want something more self contained and ad-hoc than that.
Your issue with #1 seems to be that you don’t like having different war artifacts for different environments. That’s not necessarily true as there are tricks you can do inside Lucee with environment variables to make your config dynamic. But I would challenge your desire to have a single artifact. If it’s automated by a build process, who cares. In fact, there are benefits to having a fully warmed up artifact with the server pre-started, all config deployed, etc so when you drop it in production it’s ready to go, I would also add into the #1 category (even though it can apply to anything) that you can set quite a few settings in your Application.cfc. I assume you’re aware of this, but perhaps not. You can create basic things like datasource, mail servers, and cache connections via CFML, and even mix in env vars or Java sys props here. This is pretty powerful, but does not cover 100% of what you can set in the web admin UI which is why I use CFConfig (which covers maybe 95% of the web admin) Adobe’s Application.cfc support is pretty crap too which is another reason I don’t make a habit of using it.
Your issues with #2, I’m not sure, but they seem to be centered around the fact that Lucee creates the server and web context on first start and the conig files don’t exist until then. That is true, but all the more reason I think you should be warming up your wars so none of that needs to happen on deploy. At least for production. Nonetheless, you can script in config externally, but you are correct that you’d need to know where on the drive the war will go.
I’m not actually sure if you have any issues with #3 or not. Perhaps you have your heart set on Tomcat or whatever and that’s fine. CommandBox would replace your servlet entirely and is a CLI-driven approach to startup and and shut down servers in a container mindset where each site/war is a separate process/JVM. We’ve done a lot of work to make CommandBox servers turn-key, 100% portable, and driven off JSON files which is why I keep suggesting it. We’ve spent years solving these issues that the CF Engine itself doesn’t solve in CommandBox.
It could be that no one really does this because the system doesn’t provide mechanisms to easily handle configuration at runtime.
Yes, I think you have a valid point there. That is exactly why I created CF Config (which works for Lucee and Adobe all the same). Just to reiterate, Lucee DOES support:
- A handful of one-off JVM props/env vars to toggle settings such as full null support,etc
- A decent amount of programmatic configs in Application.cfc such as datasources, etc
- Convenient access to the java system props and OS env vars in the server scope
- A VERY SMALL set of features are available via the Admin API
For everything else, the people out there not using CFCOnfig are just manually copying XML files around. That’s really the only other solution and I think it sucks which is, again, why I wrote CFConfig.
I’m just trying to leverage the functionality that is written into Lucee, namely the creation of necessary files if they are not present on
Yep, it’s a noble goal, but IMO Lucee doesn’t give you enough out of the box.
It’s a nice feature and keeps my war file clear of boiler-plate code
I’m not sure what you mean there. A “warmed up” war is not just boilerplate, it’s a lightning fast deploy in production when seconds matter. At Ortus, we use Docker swarm so all of this uses CommandBox based docker image deploying to a swarm on Digital Ocean. I can click a button and have a new container up and serving traffic in seconds. You better believe we warm the heck out of our containers, but the Gitlab build server generates those automatically so it’s no skin off our teeth to have all the files in place and ready to go,
I’m just struggling with the fact that it writes its own default config without a way to inject any additional info.
Yep, I wish Lucee did more out of the box, but it doesn’t. Hence all my suggestions to you