CODEWITHSUNDEEP
javaspringmavenspring-boot
David Welch
David Welch

Reputation: 1991

Spring Boot - Externalized properties

I've got a Spring Boot project that builds an executable war and is configured with an application.properties file and a application-dev.properties in src/main/resources.

The first line in the application.properties is spring.profiles.active=dev, which triggers the inclusion of application-dev.properties when running as expected.

My problem is that I can't seem to override these properties with an external properties source (after everything is jarred / warred up). For simple debugging, I've created a file settings.properties in the root of my project, and specified spring.profiles.active=dev,deploy in it hoping to also trigger the "deploy" profile.

However, when I run the following:

java -jar target/project-0.1.0-LOCAL-NA.war --spring.config.location=file:./settings.properties

the deploy profile is never enabled. I thought I had this working with a previous version (running 1.1.6.RELEASE now, coming from 1.0.2.RELEASE) but rolling back didn't help either.

Am I missing something obvious?

Update 1:

So while debugging I discovered that Environment.getActiveProfiles() will only return 1 item, even if there's multiple active profiles (dev & deploy in this case). So, while my reporting was only listing dev, deploy was there also.

I've got things running again by using environment variables rather than properties files for profiles, but I'd like to get everything setup with just the files...

Upvotes: 3

Views: 2880

Answers (2)

branchgabriel
branchgabriel

Reputation: 4251

When starting up with a jar file we discovered that you can't use "-D" to inject system variables. You have to use "--".

this worked for us assuming you coded your app to use profiles

    java -jar myapplication.jar
    --spring.profiles.active=override
    --spring.config.location=file:/path/to/file/application-override.properties

Upvotes: 1

David Welch
David Welch

Reputation: 1991

It's embarrassing, but I've got to own up to it: I totally misread the results I was dealing with.

--spring.config.location=settings.properties was indeed working properly. I had a combination of a logging issue & a mismatched dependency version that made things appear as if properties were not being properly populated.

FWIW

It turns out Logback interpolates the following

log.info("Profiles: {}", profileArray)

(where the array is [dev, deploy]) as Profiles: dev -- basically only showing the first element in the array. Adjusting my logging to:

log.info("Profiles: {}", Arrays.toString(profileArray) )

lead me to figure out the other issue quickly.

Upvotes: 0

Related Questions