1

I configured a very simple Spring Boot application with the following Gradle dependency:

    implementation 'org.springframework.cloud:spring-cloud-starter-bootstrap'

The idea is to embed the Spring Cloud Config Server into the application.

The content of the bootstrap.yml file is the following:

spring:
  cloud:
    config:
      server:
        bootstrap: true
        git:
          username: git
          password: <personal-access-token>
          uri: <github-uri>

The remote GitHub repo contains this application.yml file:

server:
  port: 8280

When I start the Spring Boot application it correctly retrieves the remote configuration, because the log contains the following:

Tomcat initialized with port(s): 8280 (http)
...
Tomcat started on port(s): 8280 (http) with context path ''

My question is: if I put in the remote GitHub repo a file named dummy.txt at the same level of application.yml, what is the programmatic way to retrieve its content from the application itself? I know that with separated Config Client and Config Server, from the Config Client I can rely on this in order to retrieve a plain text file from the Config Server. How to achieve the same result when the Config Server is embedded in the application?

Aldo
  • 550
  • 3
  • 13

1 Answers1

2

The best solution I got so far is based on org.springframework.cloud.config.server.resource.ResourceRepository

In a class annotate as @Service/@Component, .. just include the following:

@Autowired private ResourceRepository resourceRepo;

Next, assuming that the default profile is named default and that the configuration is stored in the branch named main, the following line of code is able to retrieve the file content:

resourceRepo.findOne(null, "default", "main", "dummy.txt").getContentAsString(StandardCharsets.UTF_8)

Note: for the @Autowired to work, the @EnableConfigServer annotation is required. This means that the application embedding the config server can leak configuration information if contacted via HTTP at a generic /foo/bar path as explained here. To mitigate the problem it is important to configure spring.cloud.config.server.prefix with an explicit value and then protect the endpoint <prefix>/*

Aldo
  • 550
  • 3
  • 13