Spring Top – Temp

Get started with Spring 5 and Spring Boot 2, through the reference Learn Spring course:

>> LEARN SPRING
Lightrun – Third Party Code
announcement - icon

Flakiness in REST requests is a common issue. A request can get a 200 OK in one scenario and a 409 next time. Sometimes a request can even succeed and fail intermittently on the same exact request. In short, working over HTTP can be a bit of a mess without solid tooling.

Also, while it’s easy enough to debug these issues locally when developing the application, we’re talking about production here - we can’t afford the downtime while you’re stepping in and out of code. Uptime is kind of the whole point.

With Lightrun, you can get the same level of access you get with a local debugger or profiler - no downtime required. You can add logs, metrics, and snapshots (think breakpoints, but without stopping the running service), in a safe and read-only manner - without redeploying, restarting, or even stopping the running service. Performance and security are maintained throughout the process.

Learn how to debug a live REST API (built with Spring, of course), using Lightrun, in this 5-minute tutorial:

>> Debugging REST Requests in Spring-Based applications using the Lightrun Platform

1. Overview

Property files are a common method that we can use to store project-specific information. Ideally, we should keep it external to the packaging to be able to make changes to the configuration as needed.

In this quick tutorial, we'll look into various ways to load the properties file from a location outside the jar in a Spring Boot application.

2. Using the Default Location

By convention, Spring Boot looks for an externalized configuration file — application.properties or application.yml in four predetermined locations in the following order of precedence:

  • A /config subdirectory of the current directory
  • The current directory
  • A classpath /config package
  • The classpath root

Therefore, a property defined in application.properties and placed in the /config subdirectory of the current directory will be loaded. This will also override properties in other locations in case of a collision.

3. Using the Command Line

If the above convention doesn't work for us, we can configure the location directly in the command line:

java -jar app.jar --spring.config.location=file:///Users/home/config/jdbc.properties

We can also pass a folder location where the application will search for the file:

java -jar app.jar --spring.config.name=application,jdbc --spring.config.location=file:///Users/home/config

Finally, an alternative approach is running the Spring Boot application through the Maven plugin.

There, we can use a -D parameter:

mvn spring-boot:run -Dspring.config.location="file:///Users/home/jdbc.properties"

4. Using Environment Variables

Now let's say that we can't alter the startup command.

What's great is that Spring Boot will also read the environment variables SPRING_CONFIG_NAME and SPRING_CONFIG_LOCATION:

export SPRING_CONFIG_NAME=application,jdbc
export SPRING_CONFIG_LOCATION=file:///Users/home/config
java -jar app.jar

Note that the default file will still be loaded. But the environment-specific property file takes precedence in case of a property collision.

5. Using Application Properties

As we can see, we have to define spring.config.name and spring.config.location properties before the application starts, so using them in the application.properties file (or the YAML counterpart) will have no effect.

Spring Boot modified how properties are handled in version 2.4.0.

Together with this change, the team introduced a new property that allows importing additional configuration files directly from the application properties:

spring.config.import=file:./additional.properties,optional:file:/Users/home/config/jdbc.properties

6. Programmatically

If we want programmatic access, we can register a PropertySourcesPlaceholderConfigurer bean:

public PropertySourcesPlaceholderConfigurer propertySourcesPlaceholderConfigurer() {
    PropertySourcesPlaceholderConfigurer properties = 
      new PropertySourcesPlaceholderConfigurer();
    properties.setLocation(new FileSystemResource("/Users/home/conf.properties"));
    properties.setIgnoreResourceNotFound(false);
    return properties;
}

Here we've used PropertySourcesPlaceholderConfigurer to load the properties from a custom location.

7. Excluding a File From the Fat Jar

The Maven Boot plugin will automatically include all files in the src/main/resources directory to the jar package.

If we don't want a file to be part of the jar, we can use a simple configuration to exclude it:

<build>
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <filtering>true</filtering>
            <excludes>
                <exclude>**/conf.properties</exclude>
            </excludes>
        </resource>
    </resources>
</build>

In this example, we've filtered out the conf.properties file from being included in the resulting jar.

8. Conclusion

This article showed how the Spring Boot framework itself takes care of externalized configuration for us.

Often, we just have to place the property values in the correct files and locations. But we can also use Spring's Java API for more control.

As always, the full source code of the examples is available over on GitHub.

Spring bottom

Get started with Spring 5 and Spring Boot 2, through the Learn Spring course:

>> THE COURSE
Generic footer banner
4 Comments
Oldest
Newest
Inline Feedbacks
View all comments
Comments are closed on this article!