Provided ConfigSource for file system properties file

[sdaschner]

We should add a 4th provided ConfigSource for a properties files that resides in the file system --
additionally to the classpath. Examples are locations such as /etc/javaconfig/ or ~/.javaconfig/. In order to support both Windows and Unix systems the default path to the properties file (whatever may chosen) should be configured, e.g. using a environment variable.

[lilian-benoit]

+1 I think a good way for externalized configuration

On Linux, we are already locations as /etc/java et ~/.java
We could have /etc/java/config et ~/.java/config

[struberg]

one way how DeltaSpike treats this http://deltaspike.apache.org/documentation/configuration.html#_propertyfileconfig

[sdaschner]

I just brainstormed a few possible solutions. I'm especially trying to see the topic from a user's perspective (not just an Expert Group member or implementer).

I see a few considerations:

• we need support for FS-based configuration which overrides other configuration
• there is a mismatch in *NIX / Windows OSes for root directories, therefore the home directory provides arguably the best compromise
• uniformity; the names should align with the file under META-INF/
• SE & EE environments have slightly different requirements; in an SE environment the config files are much more volatile and we especially want to make sure that application A doesn't easily collide with B

I see the latter as a challenge. If we load from ~/<something>.properties when <something> is the same for all applications, this will cause trouble, especially in dev environments.

From a user's perspective it would be nice and perfectly descriptive to take the name of the artifact name as filename, similar to the Servlet context names. That is, the configuration location for an app hello-acme.jar would be ~/hello-acme.properties. In an implementation, this information can be accessed via the ProtectionDomain. If the currently running Application doesn't originate from an archive, then ~/<whatever-we-decide-in-issue-31>.properties is taken.

In this week's call, we briefly mentioned ConfigSource priorities. This source would align into the priority list as follows:

1. system properties
2. environment variables
3. file system properties file (this issue)
4. archive properties file in META-INF

[jmesnil]

My expectation for this feature would be to centralize and share some configuration between applications (e.g. different deployed microservices could load their config from the same properties file).
I would then not bind the name of the config file to the name of the many application(s) that would use it.

I'd only support ${user.home}/<whatever-we-decide-in-issue-31>.properties in the spec.
Having said that, I don't know if ${user.home} is the best place to put such properties file for container platforms such as Kubernetes (instinctively, I'd put it in /etc outside of the user environment).

I agree with the ConfigSource priorities.
We could set the ordinal for the FS properties file to 110(i.e. /META-INF's ordinal + 10).
Just as an aside but we should also remember that this props file could also takes precedence over sys prop and env variable by specifying an higher config_ordinal value.