Here’s a Commandbox/Coldbox combo question: with the commandbox-dotenv module, we can create a

.env

file in the root that Commandbox will read an incorporate into Java args. In the Coldbox

config.cfc

file there is note in the “Environments” section which says

* By default we look in your

.env` file for an

environment

key, if not, then we look into this structure or if you have a function called

detectEnvironment()

. So is this just a reference to the Coldbox

dotenv

module or is it a separate process by which the CF code itself looks for the

.env

file and reads in the value?

you can see for yourself bij looking at the detectEnvironment function in ApplicationLoader.cfc. First it is calling your own detectenvironment function if present, and next it is checking this

else if ( len( util.getSystemSetting( "ENVIRONMENT", "" ) ) ) {
            configStruct.environment = util.getSystemSetting( "ENVIRONMENT", "" );
        }

so it is just calling getSystemSetting which is just checking if this ENVIRONMENT key is present in your environment variables. There are more ways to load these environment variables. In a commandbox setting dotenv is a popular way, but in some standard hosting setup with apache and lucee we didn’t need the dotenv stuff. So it is not dependant on dotenv, but in a commandbox env is it certainly an easy way to populate your vars with dotenv in a .env file. I had quite some issues with other automatic detection methods. Environmental variables is certainly the most reliable way to set the correct production or dev environment.

The docs are slightly wrong here. ColdBox I’ll look in your system environment variables and then your system Java properties for an

ENVIRONMENT

key. CommandBox DotEnv is just one way to supply those.

Agreed, I've never cared for the wording of that comment. ColdBox does not "look in" your .env file. That's sort of presumptuous and ignores the man other ways env vars (and java system props) can be set.

Huh…when did that change? I’ve thought it was still providing them as Java system props. 😅

I didn't say it changed. I said it would change in the future 🙂

Just a clarification here. The .env file creates environment variables in the server process, which are not the same as Java system properties.

This here. What is the syntax to create “environment variables in the server process?”

I'm not sure what you mean regarding syntax since the .env file, which is just a properties file is the only syntax the user needs to know.

Huh….cool. Didn’t know that was an option.

Yep, that's why we put the JVM args behind a flag with the idea to turn them off now that dotenv was able to create "proper" env vars (which wasn't the case originally)

Most of this makes sense, so thanks for the feedback. I wasn’t separating “server process” from “Java system props”, but in my brain now I am. 👍