Initializing the Configuration Server

To switch the backing repository from Git to Apache Subversion (SVN), the configuration server requires an additional connector library. This allows the framework to clone and track changes from an SVN source control system instead of a traditional version control environment.

Project Dependencies

Include the core configuration server starter alongside the official svnkit implementation. The following Maven configuration establishes the required runtime components:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.7.5</version>
    </parent>

    <groupId>com.tech</groupId>
    <artifactId>config-server-svn</artifactId>
    <packaging>jar</packaging>

    <properties>
        <spring-cloud.version>2021.0.4</spring-cloud.version>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>${spring-cloud.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-server</artifactId>
        </dependency>
        <dependency>
            <groupId>org.tmatesoft.svnkit</groupId>
            <artifactId>svnkit</artifactId>
            <version>1.10.3</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
    </dependencies>
</project>

Repository Mapping & Credentials

The application bootstrap file must point the server to the SVN repository path. Setting the default branch explicitly prevents resolution errors during startup:

server.port: 8080
spring.application.name: svc-config-backend

spring.cloud.config.server.svn.uri: https://svn.internal/repos/app-settings
spring.cloud.config.server.svn.search-paths: '*'
spring.cloud.config.server.svn.username: deploy-bot
spring.cloud.config.server.svn.password: s3cur3P@ssw0rd

# Mandatory when connecting to non-standard SVN layouts
spring.cloud.config.server.default-label: trunk
spring.profiles.active: subversion

Server Entry Point

Enable the configuration repository abstraction on the primary boot class:

package com.tech.config;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer;

@SpringBootApplication
@EnableConfigServer
public class ConfigApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigApplication.class, args);
    }
}

Once operational, requesting http://localhost:8080/{application}/{profile} returns the merged configuration files fetched directly from the SVN directory.

Enabling Dynamic Refresh on Clients

By design, Spring Cloud Config clients cache configuration values upon initial startup. Environment modifications pushed to the remote SVN store remain invisible until the microservice undergoes a full restart cycle. To bridge this gap, the Spring Boot Actuator module exposes a controlled lifecycle endpoint that forces affected beans to reload their injected properties.

Exposing Management Endpoints

Add the Actuator starter to the consumer application and whitelist the refresh capability in its configuration:

# application.yml
management:
  endpoints:
    web:
      exposure:
        include: health,info,refresh
  endpoint:
    refresh:
      enabled: true

Binding Beans to the Refresh Scope

Only classes annotated with @RefreshScope will react to hot-reload requests. Standard singleton beans retain their enitial state regardless of subsequent API triggers:

package com.tech.gateway;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RefreshScope
public class FeatureToggleController {

    @Value("${api.timeout.limit}")
    private long timeoutLimit;

    @Value("${feature.new-ui.enabled}")
    private boolean newUiActive;

    @GetMapping("/status")
    public String retrieveConfiguration() {
        return String.format("Timeout: %dms | UI Flag: %s", timeoutLimit, newUiActive);
    }
}

Triggering the Sync Operation

After updating the target property file in the SVN repository, execute an HTTP POST against the designated actuator route. The framework resolves the latest snapshot, disposes of the old bean instances, and reconstructs them with the refreshed values:

curl -X POST http://localhost:9000/actuator/refresh

Subsequent GET calls to your custom mapping will reflect the updated repository state instantly, eliminating the need for service redeployment or orchestration pauses.