Open ChristopherSchultz opened 1 year ago
There are a number of places in the code wheremirth.properties
is loaded. I would recommend having a utility method to "load the configuration" and have all those places call the unified "load configuration" method, which can then be expanded to load an extra configuration file.
Maybe DefaultConfigurationController
is already that place?
Hmm. Mirth has code paths that appear to update the on-disk properties file which may make this request essentially impossible.
I like this idea. This would make migrations and updates much more comfortable.
Based upon my previous comment, I was thinking (a) maybe I can just concatenate my "custom properties" onto mirth.properties
and (b) any re-writing done by Mirth would just take that into account.
Unfortunately, what really happens is that Mirth re-writes the properties file and randomly re-orders the default and overridden properties so that you get a combination of default and overridden ones taking effect. They must be using line-by-line parsing of properties instead of just using Properties.load()
which would normally just use last-one-read-wins semantics.
So I'm not really sure whether there are any options other than requesting a feature such as this directly from Mirth.
I guess that means "yeah, I still want this."
It's a great idea IMHO. Much like linux does include files for lots of services.
Similar to #5436, upgrades are often a hassle when trying to migrate changes to
mirth.properties
in the old version to the new version. Most of the time, you only want to customize a few things (e.g. keystore password, database URL and credentials, etc.) and everything else should be left alone.With everything in a single file, you have to basically read the whole file every time and re-apply all changes separately.
If there were another file e.g.
mirth.local.properties
that was read immediately aftermirth.properties
– allowing you to override any of the default settings – it would make upgrades easier, and possibly allow automation.