I want to start this post by bluntly saying that using a Spring Boot project as your Amazon Lambda function is a bad, bad idea, for so many reasons. I don’t want to get into that in this post. But sometimes, you can’t stop this from happening because you’re not calling the shots. Anyway, now that you are deploying a Spring Boot app to your Lambda function, let’s see how we can maintain properties in the project which are environment specific.

Reading properties in a Spring Boot app

If you have written any Spring Boot app, you’d know that you can maintain an application.properties or an application.yml file from which you can read all your properties inside a Java class using the @Value annotation. For example, let’s suppose you have the following properties in your .properties file:

aws.accessKey=yourAccessKeyHere
aws.secretKey=yourSecretKeyHere

You can read these two properties into variables in your Java code like this:

@Value("${aws.accessKey}")
private String awsAccessKey;

@Value("${aws.secretKey}")
private String awsSecretKey;

It’s super easy. There are many ways of doing this. You can create a POJO and map all ‘aws’ properties to class variables and use that class instead. I’m just showing you the easiest possible way in which we can read these properties. But the next natural question is, how can I maintain environment specific properties in the file? And that’s a very good question, let’s see how that can be done.

Maintaining environment specific properties

The .properties or .yml file that you place inside the /resource directory in your project is the default properties file. And this will be bundled into your .jar file. And when you deploy this .jar file to a UAT or a prod environment, you have to make sure you change the properties in that file. That’s inconvenient and not at all practical. And the developers of Spring Boot have thought that through. There are many ways in which you can override the properties in that bundled properties file.

You can create a new properties file in the root of the directory where the .jar file is placed. All the properties you specify in this file will override the values in the file that’s inside the .jar. That’s a convenient way, don’t you think so? You can even set environment variables on the machine where you are deploying the app. That works too. Also, you can specify the value of each and every property as command line arguments while running the .jar file.

All this is fine, but when you’re deploying a Spring Boot application as a Lambda function, you can’t make use of any of these facilities to override the default property values. So what to do now? Let’s look at that in the following section.

Overriding properties in a Lambda function

As I mentioned in the previous section, you can override the default values by creating the same properties as environment variables on the machine. And when you’re creating a Lambda function, Amazon provides the ability to define environment variables. So, in that case, it should just work, right? Well, not really.

The convention in Spring Boot, when defining properties, is that you use the dot (.) as the delimiter to separate out segments in the keys of properties (aws.accessKey, for example). But if you have worked with Amazon’s Lambda before, you’d know that you can’t have a dot in the key of an environment variable.

For this, you’d say, that’s no problem, I’ll change the properties in my code. That’s a perfectly fine solution for properties that you define. But there are a few properties that are defined by Spring Boot itself that you could be using, for example, spring.profiles.active. You can’t change this and expect Spring Boot to identify the profile correctly, right? Well, wrong.

It appears that the developers of Spring Boot have thought about these limitations too. There are a couple more ways in which you could make this work. For the most part, replace the dots in the properties with underscores, and all of Spring Boot’s properties should work just fine.

For example, I faced this exact same issue a few days back, and I used the property spring_profiles_active instead of spring.profiles.active and everything worked just fine.

I think you could now comprehend the possibilities that open up now when you think about maintaining properties in a Spring Boot application across environments. I, for one, have started exploring other awesome ways in which Spring Boot is awesome.

And if you like what you see here, or on my Medium blog, and would like to see more of such helpful technical posts in the future, consider supporting me on Patreon and Github.