MPCONFIG: identify non-static settings

[poikilotherm]

As part of the community call on 2021-02-23, @scolapasta mentioned that historically the database settings had been introduced to make config changes during runtime easier without restarting the deployment/application server. Notes for the talk, Slides of the talk, Recording of the talk

Before migrating all JVM options and Database settings to be configurable via MicroProfile Config, we should identify which settings are crucial to be updated without a restart.

Please note: this does not hold us back from still using MicroProfile Config for those. We just have to make extra sure and double check that the code re-reads any updated setting instead of injecting it statically (either by accessing it programmatically or going for injecting via Provider<>). We should also add a statement to the docs about this fact and which sources not to use then.

So, looking at you @donsizemore, @pdurbin, @landreev, @scolapasta and so many others with experience in running the service: please feel free to add your favorite dynamic setting/s below. I will edit this first comment with an updated list for each.

If there is a JVM option that hasn't been dynamic before, but you feel it should BECOME dynamic, please also comment below.

Thank you folks!

[qqmyers]

Seems like the current split between settings and jvm-options could/should be the default, i.e. the main question is whether any on one set should go in the other. Some thoughts:

• PID provider, protocol, authority, shoulder are settings but aren't very dynamic
• Some store options, such as whether to use direct upload/download, signature lifetime are jvm-options now but could be dynamic (I mostly added them there to not split store configuration, that may still be a reasonable argument to not make things dynamic but, if MP means you could enter all the info in one place and its just internal code that changes to assure re-reading, maybe that's not a concern any more)
• Shib and Solr config - currently settings that are ~static

[poikilotherm]

After careful consideration, seeing issues with the current approach in #7680 (thx @qqmyers) and people actively using the database settings to configure their Dataverse instance from an application (see #7712, thx for the hint @4tikhonov), I think I will change the direction of this.

The current approach had a mindset of migrating away from the database settings. The lack of activity here and the other use cases seem to indicate that the community is not yet ready to let go of it. Instead, I will remove the DbSettingsSource from the codebase and instead do kinda "inversion of control".

The SettingsServiceBean will be extended to

1. reference a MPCONFIG key for every option in the settings enum SettingsServiceBean.Key,
2. lookup if a value exists in MPCONFIG when SettingsServiceBean.get() type functions are called and
3. let MPCONFIG values take precedence over database settings.

This also means enforcing support to configure with MPCONFIG alone.

[poikilotherm]

During analysis of the settings referenced inside the enum, I found a very unaligned approach of historically grown ways to insert settings with the SettingsServiceBean:

1. Simple untyped key-value settings, present in the Key enum, documented, parsing to a typed value happens on request
2. Array settings using a comma separated list (splitting happens in requesting code, usually documented)
3. Map settings using the setting name extended with a colon and the map key (documented)
4. Compound settings using a JSON value (parsing happens in requesting code, documented)
5. Localized settings (language stored as attribute in DB, too, setting via special API URL, documented)
6. At least one setting referencing another setting by arbitrary name (a setting that you name as you want it, documented)
7. A few undocumented (unused) setting keys within the enum
8. A few setting names in requesting code not present in the enum, (ab)using the functionality to retrieve arbitrary settings by name (WorkflowAdmin as an undocumented example, BuiltinUsers.Key as documented example)

The current concept does not save types of a setting (only the requesting code knows) and there are no validation or constraints on setting, this is left as an exercise to the requesting code.

🙈 I did it again, stiring up a hornet's nest 🐝