[IDEA] Allow multiple MC configuration files t be read on startup

[ChristopherSchultz]

I hate having to re-build mirth.properties and others for each upgrade because there are new things in it. I would love to have a single default config file that ships with every version, but my actual configuration ends up being in a file that doesn't get overwritten and doesn't need to be manually merged-into the new one.

If the product would ship with a default properties file containing certain things (like defaults!) and then you could overlay others, that would be very beneficial.

So instead of a single file to load, it will load a few things, in order.

Always load oie.properties first. Then, load mirth.properties as a really convenient migration strategy for existing users, and overwrite any previous values with stuff from mirth.properties. Then, read local.properties and overwrite again.

Anyone who wants to can use mirth.properties forever. But the product can change it's default default filename to something that doesn't say "mirth" anymore.

If you want to go crazy, you can read files.to.load from oie.properties, then append anything that any of the files.to.load also requests, and so on. So mirth.properties or local.properties can set files.to.load=database.properties and then OIE also loads database.properties even though it wasn't known about in advance.

You could do the same for logging configuration, but I'm not sure how well that would work with the current log4j system. It would be enough to layer primary configuration files (i.e. what is currently mirth.properties).

[leovander]

The way I have gotten around that in node at least, is making a default config object, and when the env file is loaded via dotenv, the default values get added to the user provided env config object, not overriding the user provided values

https://github.com/motdotla/dotenv?tab=readme-ov-file#populate

the app loads the env file at start (either root folder of project) or given a path as a run time param.

I think the only thing to call out here, is taking into account how the files should be processed when property is already defined?

• preserve the existing value
• override the existing value

[ChristopherSchultz]

My proposal matches your precedence order, but processes the files in the reverse order: from most-generic to most-specific. So the stock oie.properties file would be read first, followed by local-config.properties (or whatever) and the values from later files always overwrite whatever has already been loaded by the more-general files.

[tonygermano]

See https://commons.apache.org/proper/commons-configuration/apidocs/org/apache/commons/configuration2/CombinedConfiguration.html