-
Notifications
You must be signed in to change notification settings - Fork 0
Add mutable spring-backed config QUES-36 #43
Conversation
dace286
to
415e92f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
|
||
import java.lang.annotation.*; | ||
|
||
@Target({ElementType.TYPE, ElementType.METHOD}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need it to be on both type and method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I think I copied this from someone on the web somewhere. I guess in principle you could have individual tests that are marked as integration tests, but that seems like a bad fit with our use cases. I think I might remove the METHOD option
c05e5b3
to
15861e4
Compare
…t apps QUES-36 Also move Spring boot tools into their own module to avoid pulling in unnecessary dependencies to non-spring-boot apps.
15861e4
to
7d3eedb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for the extensive documentation comments.
* return the updated values on the next method call to one of the property getters. As yet there is no | ||
* mechanism for notifying clients that an update has occured (although in principle this would not be difficult) | ||
* nor does it make any attempt to ensure that any dependencies of these properties beans - including spring | ||
* infrastructure that may have been wired together according to their values - are dynamically updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 thanks for the explanation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well done, thanks!
pom.xml
Outdated
<groupId>org.springframework</groupId> | ||
<artifactId>spring-test</artifactId> | ||
<version>${spring.version}</version> | ||
<scope>compile</scope> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think spring Test shouldn't end up in prod code, compile is the default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot to push submit...
spring-boot-infrastructure/pom.xml
Outdated
<dependency> | ||
<groupId>org.springframework</groupId> | ||
<artifactId>spring-test</artifactId> | ||
<scope>compile</scope> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here
spring-boot-infrastructure/pom.xml
Outdated
<dependency> | ||
<groupId>org.junit.jupiter</groupId> | ||
<artifactId>junit-jupiter-api</artifactId> | ||
<scope>compile</scope> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test related deps should be test scoped, or in another module which is only used as test scope. Test related deps are in commons-testing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so this tag should be in commons-testing then? Obviously it can't have test scope because it's a library for use in other tests. I can move it to a module in commons-testing, that's fine
|
||
@Override | ||
public boolean isMutableConfigEnabled() { | ||
return getBoolean("mutableConfig.enabled", false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of copy pasting the constant pls use ConfigStorage#MUTABLE_CONFIG_KEY
* infrastructure that may have been wired together according to their values - are dynamically updated. | ||
*/ | ||
@ParametersAreNonnullByDefault | ||
public class SpringBootConfigStorage extends AbstractBaseConfigStorage implements ImmutableConfigStorage { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a mutable store, then why does it implement ImmutableConfigStorage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I wasn't really sure what to do here. This can be both a mutable and immutable store. Honestly, I'm not sure that the interface separation between the two is actually doing much for us. In practice every client of the existing code uses the factory, which creates an implementation based on the value of the mutable config property. In particular, I'm not sure what the getImmutableConfigStorage
method does for us - AFAICT nothing in any project ever calls this. I was thinking about just removing the interfaces and having a single ConfigStorage interface with the two RawConfigStorage implementations + this one... but then I thought about updating PKB Common everywhere and I chickened out. I guess i can look at this again.
* infrastructure that may have been wired together according to their values - are dynamically updated. | ||
*/ | ||
@ParametersAreNonnullByDefault | ||
public class SpringBootConfigStorage extends AbstractBaseConfigStorage implements ImmutableConfigStorage { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few integration test would be good, to prevent any unintended regression early on.
Moved test utilities + deps to commons-testing project Got rid of unhelpful marker interfaces Add some testing (unit + integration) for SpringBootConfigStorage
...frastructure/src/test/java/com/pkb/common/config/SpringBootConfigStorageIntegrationTest.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making the changes!
Add mutable spring-backed config QUES-36
Add mutable configuration for spring environment to allow easier integration between Spring Boot apps and PKB e2e properties framework