I have coldbox running with Lucee. I created a SQL server datasource in Lucee. I know there are a couple of ways to set the datasource (application.cfc, config.json). Then I see the env file that loads connection strings and user names and passwords. If I have the DS set up in Lucee do I need all the env stuff?
What is happening for me is that when the server starts or restarts and loads the env config it is changing my Lucee datasource and breaking it. I am guessing it is because I am not specyfying the correct info for the env config. Here is what I have:
Do I need to load all that if the DS is set up in Lucee? It seems like I just need to tell the environment what DS it should be using between prod, dev, test etc.
When I first create the DS the type is listed in Lucee as Microsoft SQL Server (Vendor Microsoft). After a restart it changes to Other - JDBC Driver (deprecated) and no longer connects.
Probably not. The .env file will be most useful if your application is being deployed somewhere like Docker where you use env vars in stage and production to specify these details. In which case, the .env file is simply the development version of those settings. But if you don’t want to load settings from the environment, then you probably don’t care about that file.
That’s not exactly what’s happening, but you’re close. The .env file alone won’t load any settings into your server, HOWEVER I assume you probably have a .cfconfig.json file in the web root (which comes with all our application templates as an example). The existence of this .cfconfig.json file by convention will cause the CFConfig module in CommandBox to import all datasources from the JSON, overwriting whatever manual datasources you may have created. You can see this in the output of the server start command, especially if you add the --verbose flag.
You basically need to choose. Is CFConfig going to be managing your datasources, or are you going to be doing it manually? Because right now, you’re trying to do both. If you want to use CFConfig, set up the datasources you want in the Lucee web admin UI and use
cfconfig export .cfconfig.json
to export the config you want into the JSON file. But if you want to just manually control it all (which I’ll warn you, may sound “easier” right now, but will create more work for you the instant a new Lucee update comes out) then just delete the .cfconfig.json file and be done. You can also delete the .env as well if you’re not using any of those settings in your ColdBox app. (For example via getSystemSetting() in the /config/Coldbox.cfc)
It’s worth noting here that the CFConfig module doesn’t really do anything with your .env file directly. There is a nexus of several modules all interacting here, and without seeing everything in you project, I really can’t tell you exactly what you have or don’t have going on.
When you start a server in CommandBox, CFConfig will load any config it finds in a .cfconfig.json file OR another file name if configured in your server.json
JSON files in general in CommandBox allow you to put placeholders inside of them which will pull from CommandBox env vars, System properties, and OS env vars. They look like this: ${DB_PORT}
The commanbdox-dotenv module will look for and load Commandbox env vars that only exist for the duration of that command every time you start a server or run any command in the CLI. That is what is reading your .env file and dumping the env vars into the shell for whoever wants to use them (such as CFConfig)
So what’s common is for dotenv to load env vars out of the .env file, which are then used by CFConfig to replace the ${foobar} placeholders in the .cfconfig.json file, which is imported into your starting server to overwrite all the config.
None of the bullets above are a requirement to use CommandBox servers. It’s all 100% optional. We include it in our application templates because we think it’s the easiest and most standard way.
Hard to say without seeing what you have going on. I’d say you first need to back up and decide where you’re configuration is coming from, and where you WANT it to be coming from. Then once you understand and simplify the process, the rest of the issues will probably go away.
Excellent. it’s a bit of a shift of mentality to get used to allowing a JSON file to control your configuration instead of doing it manually, but it offers a great deal of freedom. Now you can remove, upgrade, or even change engines on your server and all your config will come back every time like it never left. The JSON file allows you to bake the configuration element that used to be manual right into your project and share it with any other devs who want to be able to spin up the same site as you on their local machine. And with things like passwords extracted out in the .env file, it can be safe to commit to the repo.