Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider Initialization on demand for ConfigurationProviderResolver #55

Open
agentgt opened this issue Mar 1, 2018 · 0 comments
Open

Comments

@agentgt
Copy link

agentgt commented Mar 1, 2018

The ConfigProvider (EDIT on name... apologies) has a static initializer.

For static initialization I usually use this pattern See https://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom to avoid unnecessary loading.

Thus

private static final ConfigProviderResolver INSTANCE = ConfigProviderResolver.instance();

Should be:

private static class LazyHolder { private static final ConfigProviderResolver INSTANCE = ConfigProviderResolver.instance(); }

Also sort of off topic but I was actually trying to get a configuration standard 2 years ago: https://github.com/agentgt/configfacade

I didn't have the clout or time to devote to pushing it so I'm excited about the future of this library.

I hadn't separated out enough of the "helper" functionality from the base interfaces in my version as I was still experimenting with the ergonomics of the library as well as I was also trying to add reloadable behavior and listeners (similar to archaius).

I think reloadable/listening behavior is important and might file an issue to maybe add support if thats OK.

jeanouii pushed a commit to jeanouii/ConfigJSR that referenced this issue Mar 8, 2018
jeanouii pushed a commit to jeanouii/ConfigJSR that referenced this issue Mar 8, 2018
jeanouii pushed a commit to jeanouii/ConfigJSR that referenced this issue Mar 8, 2018
* the DuckConverter must be added as a service provider to be discovered
* add missing @test annotion to testCustomConverter
* update ConfigProviderResolver#getBuilder javadoc to specify that a
  fresh config builder will discover converters using the ServiceLoader
  pattern.

Signed-off-by: Jeff Mesnil <[email protected]>
jeanouii pushed a commit to jeanouii/ConfigJSR that referenced this issue Mar 8, 2018
jeanouii pushed a commit to jeanouii/ConfigJSR that referenced this issue Mar 8, 2018
Signed-off-by: Emily Jiang <[email protected]>
jeanouii pushed a commit to jeanouii/ConfigJSR that referenced this issue Mar 8, 2018
agentgt added a commit to agentgt/ConfigJSR that referenced this issue May 14, 2019
The `ConfigProviderResolver` should not initialize on just being imported for a variety of reasons.
The major reasons is makes initialization less predictable and bootstrapping more complicated. Performance is also a reason. 
Instead it should be initialized on access just like logging frameworks and many other Java frameworks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant