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

Reuse MapPropertySource for DynamicValuesPropertySource implementation (as a template for custom variants) #32110

Closed
philwebb opened this issue Jan 24, 2024 · 2 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) in: test Issues in the test module type: enhancement A general enhancement
Milestone

Comments

@philwebb
Copy link
Member

philwebb commented Jan 24, 2024

Currently Spring Boot has it's own version of DynamicValuesPropertySource called TestcontainersPropertySource. This class is testcontainers specific and includes some extra functionality, but the basic logic for the core methods is copy/paste from the package-private framework class.

Recently @rwinch has started to reuse TestcontainersPropertySource in the spring-boot-testjars experimental project. This isn't ideal since that project should not depend on spring-boot-testcontainers. We can't move TestcontainersPropertySource and there isn't a good home in Spring Boot to create another public variant so we wondered if the Spring Framework class should be made public instead?

The alternative is to copy/paste the code again into spring-boot-testjars.

@philwebb philwebb changed the title Make DynamicValuesPropertySource public Consider making DynamicValuesPropertySource public Jan 24, 2024
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jan 24, 2024
@jhoeller
Copy link
Contributor

If I understand that right, Rob would have to copy-and-paste the Testcontainers part of it in any case, so this is primarily about a common base class for that copy?

For a start, we could let DynamicValuesPropertySource extend MapPropertySource (relaxing the latter's generics to Map<String, ?>) so that it just needs to override getProperty. Since getProperty is being customized in TestContainersPropertySource anyway, copying the two common lines of that method from DynamicValuesPropertySource does not seem to be too bad. We could repurpose this issue for such a MapPropertySource-based arrangement in 6.1.4.

@jhoeller jhoeller added in: test Issues in the test module in: core Issues in core modules (aop, beans, core, context, expression) labels Jan 25, 2024
@jhoeller jhoeller self-assigned this Jan 25, 2024
@jhoeller
Copy link
Contributor

jhoeller commented Jan 25, 2024

With this applied, the non-public DynamicValuesPropertySource looks like this, serving as a template for custom copies:

class DynamicValuesPropertySource extends MapPropertySource<Supplier<Object>> {

	DynamicValuesPropertySource(String name, Map<String, Supplier<Object>> valueSuppliers) {
		super(name, valueSuppliers);
	}

	@Override
	public Object getProperty(String name) {
		return SupplierUtils.resolve(this.source.get(name));
	}
}

@sbrannen sbrannen changed the title Consider making DynamicValuesPropertySource public Consider making DynamicValuesPropertySource public Jan 25, 2024
@jhoeller jhoeller removed the status: waiting-for-triage An issue we've not yet triaged or decided on label Jan 26, 2024
@jhoeller jhoeller changed the title Consider making DynamicValuesPropertySource public Reuse MapPropertySource for DynamicValuesPropertySource implementation (as a template for custom variants) Jan 26, 2024
@jhoeller jhoeller added the type: enhancement A general enhancement label Jan 26, 2024
@jhoeller jhoeller added this to the 6.1.4 milestone Jan 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) in: test Issues in the test module type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

3 participants