Add a ConfigResourceClient for plain text and binary files by sharanggupta · Pull Request #3355 · spring-cloud/spring-cloud-config

sharanggupta · 2026-10-22T15:29:08Z

Ports the ConfigResourceClient from the commercial config client (spring-cloud-services-starters, Apache 2.0; original authors kept in the Javadoc), as suggested on the issue, so that an application can read the plain text and binary files the config server serves with the same settings that loaded its configuration.

PlainTextConfigClient, BinaryResourceConfigClient and ConfigResourceClient are the ported API; DefaultConfigResourceClient is the RestClient based implementation, with the application name, profile and label coming from ConfigClientProperties.
ConfigServerConfigDataLocationResolver exposes the RestTemplate that loaded the configuration as configClientRestTemplate and a RestClient built from it as configClientRestClient when the bootstrap context closes, as the commercial resolver does, so the client carries the URI, credentials, headers, TLS settings, timeouts and token of the import.
ConfigResourceClientAutoConfiguration creates the ConfigResourceClient when that RestClient bean exists and no custom client is defined.

Differences from the commercial code, all because the open source client has no default label: without a label the request uses ?useDefaultLabel, a slash in a label is escaped as (_) as ConfigServerConfigDataLoader does, a nested path is sent segment by segment, and the profile falls back to default when none is configured.

Tests cover the request paths, headers, defaults and error cases against a MockRestServiceServer, the auto-configuration conditions, and that a spring.config.import=configserver: import exposes the beans; the client module suite passes. The client docs gain a "Reading Plain Text and Binary Files" section.

Port the ConfigResourceClient of the commercial config client into the client module, so that an application can read the plain text and binary files the config server serves with the same settings that loaded its configuration: the config data resolver exposes the RestTemplate that loaded the configuration and a RestClient built from it as beans, and the auto-configuration creates the client from them. Without a label the request asks the server for its default label, a slash in a label is escaped as the config data loader does, and a nested path is sent segment by segment. Fixes spring-cloudgh-789 Signed-off-by: Sharang Gupta <sharang@sharanggupta.dev>

A context can hold two ConfigClientProperties beans, the one resolved by the config server import and the one bound by ConfigClientAutoConfiguration, which made the configResourceClient bean fail to resolve its dependency in the sample application. Prefer the imported properties, which describe the server the RestClient talks to. Signed-off-by: Sharang Gupta <sharang@sharanggupta.dev>

ryanjbaxter · 2026-10-22T20:50:27Z

+			}
+		}
+		if (label == null) {
+			label = this.properties.getLabel();


The label could be a comma separated list

The label is now split like the loader does and tried one label at a time, a 404 moving on to the next; the last 404 is thrown.

A list like a,,b yields an empty element, which buildUri treats as "no label" and turns into ?useDefaultLabel. Should empty elements be skipped?

Yes, in 4f5fa67: empty elements are skipped, and a list of only empty elements uses the server's default label.

ryanjbaxter · 2026-10-22T20:54:17Z

+		try {
+			beanFactory.registerSingleton(REST_CLIENT_BEAN_NAME, RestClient.create(restTemplate));
+		}
+		catch (RuntimeException ex) {


Can you explain what this is for?

The resolver adds the close listener every time resolveProfileSpecific runs, which is once per import location and per profile pass, and addCloseListener does not deduplicate, so the listener runs several times when the bootstrap context closes; registerSingleton refuses a name that already exists, so the guard makes the registration idempotent. I have put that in a comment.

In production it turns any failure into a debug-level log and a missing ConfigResourceClient bean, which then shows up as an unexplained NoSuchBeanDefinitionException. I'd either let the exception propagate and fix the test double

…nfigResourceClient The client now behaves like the config server import when it reads a file: the credentials of each URI (explicit, from the URI's user info, or the configured authorization header) are sent, every URI is tried according to the multiple-uri-strategy, and a comma-separated label is tried one label at a time, a 404 moving on to the next. A file is read into memory up to spring.cloud.config.resource-client.max-size (1MB by default) and rejected beyond it, so a large file cannot exhaust the heap. The RestTemplate and RestClient of the import are no longer registered as beans, which would clash with an application's own by-type injection and expose the config server's headers and interceptors. The resolver registers a package-private ConfigServerRestClientHolder instead, which only the auto-configuration consumes. See spring-cloudgh-789 Signed-off-by: Sharang Gupta <sharang@sharanggupta.dev>

sharanggupta · 2026-10-23T03:06:07Z

Thanks for the review, @ryanjbaxter. Pushed as a follow-up commit and replied to each point inline.

ryanjbaxter · 2026-10-30T14:32:10Z

+			return this.maxSize;
+		}
+
+		public void setMaxSize(DataSize maxSize) {


We should validate this in some way. A negative number does not really make sense in this case. Also I wonder if setting it to 0 would be away to disable the limit?

Done in 4f5fa67: a negative size is rejected and 0 disables the limit.

ryanjbaxter · 2026-10-30T14:37:04Z

+		return getResource(profile, label, path, true);
+	}
+
+	private Resource getResource(String profile, String label, String path, boolean binary) {


When a URI is skipped nothing is logged. The loader logs "Will try the next url if available". If every attempt fails, only the last exception surfaces, so someone debugging a failed read can't see which servers or labels were tried.

Could we log the skipped URI and label at info or debug level?

Done in 4f5fa67: each skipped URI and label is logged at info, ending with "Will try the next url if available" like the loader.

ryanjbaxter · 2026-10-30T14:38:12Z

+			}
+		}
+		if (label == null) {
+			label = this.properties.getLabel();


A list like a,,b yields an empty element, which buildUri treats as "no label" and turns into ?useDefaultLabel. Should empty elements be skipped?

ryanjbaxter · 2026-10-30T14:39:21Z

+		try {
+			beanFactory.registerSingleton(REST_CLIENT_BEAN_NAME, RestClient.create(restTemplate));
+		}
+		catch (RuntimeException ex) {


In production it turns any failure into a debug-level log and a missing ConfigResourceClient bean, which then shows up as an unexplained NoSuchBeanDefinitionException. I'd either let the exception propagate and fix the test double

A failed read now shows which servers and labels were tried, and a RestClient that cannot be built fails instead of hiding the client bean. Signed-off-by: Sharang Gupta <sharang@sharanggupta.dev>

ryanjbaxter · 2026-10-30T18:15:12Z

 	@Test
 	void context() {
 		RestTemplate rest = mock(RestTemplate.class);
+		when(rest.getErrorHandler()).thenReturn(new DefaultResponseErrorHandler());


Now that I see this, I understand better why the catch was there originally. Lets add it back, an optional component must not prevent startup. Sorry about that!

Restored in 88822f1, logged at warn.

The ConfigResourceClient is optional, so a RestTemplate that cannot back a RestClient must not prevent startup; log it at warn to explain the bean. Signed-off-by: Sharang Gupta <sharang@sharanggupta.dev>

kvmw

Approved with a minor comment on API visibility.

Only the auto-configuration creates it. Signed-off-by: Sharang Gupta <sharang@sharanggupta.dev>

ryanjbaxter · 2026-11-02T21:01:25Z

As soon as my other feedback is addressed we can merge this PR

sharanggupta mentioned this pull request Oct 22, 2026

Enhance client side resolution of plain-text files #789

Closed

spring-cloud-issues added the waiting-for-triage label Oct 22, 2026

ryanjbaxter requested changes Oct 22, 2026

View reviewed changes

ryanjbaxter reviewed Oct 30, 2026

View reviewed changes

Validate max size, log skips, skip empty labels

4f5fa67

A failed read now shows which servers and labels were tried, and a RestClient that cannot be built fails instead of hiding the client bean. Signed-off-by: Sharang Gupta <sharang@sharanggupta.dev>

ryanjbaxter requested changes Oct 30, 2026

View reviewed changes

Keep the RestClient holder failure non-fatal

88822f1

The ConfigResourceClient is optional, so a RestTemplate that cannot back a RestClient must not prevent startup; log it at warn to explain the bean. Signed-off-by: Sharang Gupta <sharang@sharanggupta.dev>

kvmw approved these changes Nov 2, 2026

View reviewed changes

Comment thread ...lient/src/main/java/org/springframework/cloud/config/client/DefaultConfigResourceClient.java Resolved

Make DefaultConfigResourceClient package-private

d30c6dc

Only the auto-configuration creates it. Signed-off-by: Sharang Gupta <sharang@sharanggupta.dev>

ryanjbaxter merged commit deb8de2 into spring-cloud:main Nov 3, 2026
2 checks passed

Conversation

sharanggupta commented Oct 22, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

sharanggupta commented Oct 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kvmw left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ryanjbaxter commented Nov 2, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants