Skip to content
This repository has been archived by the owner on Jun 25, 2024. It is now read-only.

Add mutable spring-backed config QUES-36 #43

Merged
merged 8 commits into from
Nov 10, 2020
Merged

Add mutable spring-backed config QUES-36 #43

merged 8 commits into from
Nov 10, 2020

Conversation

symposion
Copy link
Contributor

@symposion symposion commented Oct 26, 2020

Add mutable configuration for spring environment to allow easier integration between Spring Boot apps and PKB e2e properties framework

r-oylo
r-oylo previously approved these changes Nov 5, 2020
Copy link
Contributor

@r-oylo r-oylo left a 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})
Copy link
Contributor

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?

Copy link
Contributor Author

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

@symposion symposion added dont-merge-yet Don't merge this yet and removed dont-merge-yet Don't merge this yet labels Nov 6, 2020
@symposion symposion changed the title Add integration test annotation for Spring Boot apps QUES-36 Add integration test annotation +mutable spring-backed config QUES-36 Nov 6, 2020
@symposion symposion force-pushed the feature/ques-36 branch 2 times, most recently from c05e5b3 to 15861e4 Compare November 6, 2020 15:23
…t apps QUES-36

Also move Spring boot tools into their own module to avoid pulling in unnecessary
dependencies to non-spring-boot apps.
MFAshby
MFAshby previously approved these changes Nov 9, 2020
Copy link
Contributor

@MFAshby MFAshby left a 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.
Copy link
Contributor

Choose a reason for hiding this comment

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

👍 thanks for the explanation

r-oylo
r-oylo previously approved these changes Nov 9, 2020
Copy link
Contributor

@r-oylo r-oylo left a 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>
Copy link
Contributor

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

Copy link
Contributor

@karsaig karsaig left a 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...

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
<scope>compile</scope>
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here

<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<scope>compile</scope>
Copy link
Contributor

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

Copy link
Contributor Author

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);
Copy link
Contributor

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 {
Copy link
Contributor

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

Copy link
Contributor Author

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 {
Copy link
Contributor

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
@symposion symposion dismissed stale reviews from r-oylo and MFAshby via 6a952a7 November 10, 2020 11:17
@symposion symposion changed the title Add integration test annotation +mutable spring-backed config QUES-36 Add mutable spring-backed config QUES-36 Nov 10, 2020
Copy link
Contributor

@r-oylo r-oylo left a 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!

@karsaig karsaig merged commit a65ddd9 into master Nov 10, 2020
@karsaig karsaig deleted the feature/ques-36 branch November 10, 2020 18:38
MFAshby pushed a commit that referenced this pull request Jul 5, 2022
Add mutable spring-backed config QUES-36
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
4 participants