ConfigProvider is a bit crowded

[struberg]

We should probably move a few bits from the ConfigProvider out of the eyes of the casual user.
We could e.g. move the following methods to ConfigProviderResolver:

• registerConfig
• releaseConfig
• ConfigBuilder inner interface

[struberg]

Any comments about this idea?

[gunnarmorling]

I looked at the PR, but I couldn't fully figure how you envision all the pieces to be used. Maybe you could sketch some code using them to clarify the picture?

[struberg]

You mean the features itself or just the refactoring?

I just moved the methods from ConfigProvider to ConfigProviderResolver.
So the usage would be ConfigProviderResolver.getInstance().setConfig() etc.

[gunnarmorling]

The purpose of ConfigProviderResolver isn't quite clear to me.

Its comment says "Service provider for ConfigProviderResolver". Should it be "Service provider for ConfigProvider"?

[struberg]

@gunnarmorling ConfigProviderResolver was initially a small internal interface delegating 1:1 to the internal implementation. Please feel free to suggest a better name for that class in a separate ticket.