Skip to content

Conversation

@ibauersachs
Copy link
Member

Closes #234

@ibauersachs ibauersachs changed the base branch from master to release/3.4.x November 22, 2021 22:34
@ibauersachs ibauersachs requested a review from nresare November 22, 2021 22:34
Copy link
Member

@nresare nresare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems fine to me. One could argue that making refresh always succeed would make this a tiny bit more straight forward, but I have no strong opinion about this. Approved.

@ibauersachs
Copy link
Member Author

This seems fine to me. One could argue that making refresh always succeed would make this a tiny bit more straight forward, but I have no strong opinion about this. Approved.

I'm not sure what you mean. Do you see a case where it still fails?

@nresare
Copy link
Member

nresare commented Nov 23, 2021

I just meant that if we want ResolverConfig.refresh() to always succeed, even when configProviders have not yet been set, we can do that. That would be less fragile than making sure that refresh() is only called after checkInitialized() is called.

My preferred solution would be to move the init code from checkInitialized() to the constructor, as that would man that partially initialised objects (where configProviders are not yet set) would never exist.

@ibauersachs
Copy link
Member Author

I just meant that if we want ResolverConfig.refresh() to always succeed, even when configProviders have not yet been set, we can do that. That would be less fragile than making sure that refresh() is only called after checkInitialized() is called.

My preferred solution would be to move the init code from checkInitialized() to the constructor, as that would man that partially initialised objects (where configProviders are not yet set) would never exist.

configProviders is static, so I cannot completely avoid having checkInitialized() in getCurrentConfig() and getConfigProviders(). But I can move the first part into the constructor, keeping only currentConfig == null to eventually call refresh.

@sonarqubecloud
Copy link

sonarqubecloud bot commented Dec 3, 2021

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

90.5% 90.5% Coverage
0.0% 0.0% Duplication

@ibauersachs ibauersachs merged commit 8c2b9a5 into release/3.4.x Dec 5, 2021
@ibauersachs ibauersachs deleted the bugfix/refresh branch December 5, 2021 14:02
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

Successfully merging this pull request may close these issues.

ResolverConfig.refresh() does not perform checkInitialized() ?

3 participants