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

Provide better hooks for testing the creation of an object with a given config #23

Open
bbaldino opened this issue Sep 11, 2020 · 0 comments

Comments

@bbaldino
Copy link
Member

bbaldino commented Sep 11, 2020

A few times now I've ran into a use case where I wanted to create an instance of a class with a given configuration. The first thought is to do something like this:

setNewConfig(<some new config>)
val myInstance = MyInstance()
setNewConfig(<previous config>)

But this doesn't work, as configuration values are retrieved lazily, so the property won't be retrieved until it is accessed, which will likely be after the previous config has already been restored in the above block.

So my second thought was to add a new MetaconfigSetting which would disable the laziness so that values would be retrieved immediately and then the intended config would be read. I did this by adding the following to Cache:

init {
    if (MetaconfigSettings.retrieveValuesImmediately) {
        cachedValue
    }
}

So that it would trigger retrieving the value right away if MetaconfigSettings.retrieveValuesImmediately was set to true. This, does not work, as the supplier passed to Cache is the abstract doGet method in ConfigValueSupplier and, since the cache is implemented in the parent type, when it is created the subclass (the actual supplier implementation) isn't fully created yet, so doGet fails to run properly. This means that the retrieval of the property would have to happen in all the ConfigValueSupplier subclasses themselves (to ensure that they have been fully created first). Because we currently only ever override values which come from ConfigSourceSupplier, this may be acceptable for now but it would be nice to have a more generic solution.

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