Environment variables and system properties

[modius]

With reference to this recent addition to next-gen Lucee:

add system properties and system environments setting to server scope
[LDEV-344] - Lucee

LDEV-344 #deployed
https://bitbucket.org/lucee/lucee/commits/50015c1c9e6bd578804bf2690ecaea78c639221e

This creates two structs under the server scope:

• server.system.environment; for all the local OS environment variables puled from enumerating System.getEnv()
• server.system.properties; for all the JVM system properties pulled from enumerating System.getProperties()

Firstly, i think this is a great idea. While at first it feels icky to stick anything into the server scope, upon reflection it seems like an elegant way of doing a little bit of plumbing we’d otherwise have to do in the Application.cfc constructor. It’s a wonder this hasn’t always been part of server scope as it feels very CFML.

The general nomenclature is environment variables and system properties so I can understand the naming decision. However, both come from the System class, and the names are often used interchangeably; for example, JVM environment properties. This has caused considerable debate amongst the developers in our office – naming things is always hard.

A less ambiguous naming of the variable scopes might be:

• server.env; marries up to the function call System.getEnv()
• server.properties; marries up to the function call System.getProperties()

[adam_cameron]

@modius

A less ambiguous naming of the variable scopes might be:

• server.env; marries up to the function call System.getEnv()
• server.properties; marries up to the function call System.getProperties()

I think this is an excellent, sensible, idea.

My one slight apprehension is creating an abbreviated variable name: env rather than just environment. Obviously there’s a completely legit mapping of env back to getEnv(), and following that makes some sense. However needlessly (?) abbreviating variable names does make my eyes narrow slightly.

Thoughts?

That said, I don’t think it’s a major thing. Just an observation.

–
Adam

[apenhorwood]

I like this idea. Currently I am doing similar things in my framework but this would save me time creating the java calls to get that data.

Andrew Penhorwood

[modius]

@adam_cameron

My one slight apprehension is creating an abbreviated variable name: env rather than just environment. Obviously there’s a completely legit mapping of env back to getEnv(), and following that makes some sense. However needlessly (?) abbreviating variable names does make my eyes narrow slightly.

Another thing in its favour is env is the shell command to print all environment variables to stdout

$ env
TERM_PROGRAM=iTerm.app
LESS_TERMCAP_md=
...

[adam_cameron]

@modius

@adam_cameron

My one slight apprehension is creating an abbreviated variable name: env rather than just environment. Obviously there’s a completely legit mapping of env back to getEnv(), and following that makes some sense. However needlessly (?) abbreviating variable names does make my eyes narrow slightly.

Another thing in its favour is env is the shell command to print all environment variables to stdout

$ env
TERM_PROGRAM=iTerm.app
LESS_TERMCAP_md=
...

Yeah,entirely fair enough. It makes good sense to stick with env then. Cheers Geoff.

–
Adam