I am currently getting back to coding in Java + Spring after about 8 years. In the last 8 years, the time I spent on coding has gone significantly as I am now into leadership roles that take me away from writing code. Having said that, I need to understand some level of coding, especially in the Java world, as that\u2019s the language in which I find most of my projects, and I cannot help my teams effectively unless I am familiar with coding. So much has changed since I stopped coding, and I am learning everything again. This is the first of the many articles I will write to get as I know new things. Also, I am building an application more from my personal fruition. I generally cannot spend consistent time, which allows me to spend more time learning instead of trying to meet the deadlines of an actual life client project.<\/p>\n
In this post, I will talk about how to use externalize configurations in a Spring Boot application.<\/p>\n
We will use Spring Boot\u2019s default setup to create some configurations and read them in our application. We will also look at a simple key-value way of setting up properties and YAML based configurations.<\/p>\n
I prefer using YAML and from this point onwards I will only be using YAML bases setups.<\/p>\n
During my implementation run, I noticed that I was eventually required to use the spring-boot-configuration-processor dependency. Else I would get an error, and the code would not compile. I didn\u2019t find much on why this is needed in my research, but adding this dependency resolved the issue for me.<\/p>\n
The second dependency I have added is for Actuator, which gives us some exciting tools. This is unnecessary, but if you are looking to debug your properties and find more configurations to work with, I will suggest you add this as well.<\/p>\n
<dependency>\n <groupId>org.springframework.boot<\/groupId>\n <artifactId>spring-boot-configuration-processor<\/artifactId>\n <optional>true<\/optional>\n <\/dependency>\n <dependency>\n <groupId>org.springframework.boot<\/groupId>\n <artifactId>spring-boot-starter-actuator<\/artifactId>\n <\/dependency><\/pre>\n3. Setting up Configuration Files<\/h2>\n
The following code is for application.properties file which is the default format you will get in Spring Boot.
<\/div> <\/div><\/p>\n# This is to expose all the endpoints for Actuator. use * for all ONLY in DEV\nmanagement.endpoints.web.exposure.include=*\n\n# Custom Properties\nbungie.rootPath=\"https:\/\/www.bungie.net\/Platform\"\nbungie.apiKey=000999888111<\/pre>\nThe following is same properties for in YAML format.<\/p>\n
bungie:\n rootPath: \"https:\/\/www.bungie.net\/Platform\"\n apiKey: 000999888111<\/pre>\n4. Creating the Bean that will read these configurations<\/h2>\n
Now that we have created the properties, we have 2 use cases that we need to consider when reading the properties.<\/p>\n
\n
- Reading One off property<\/strong> \u2013 In this case, we may need to create a property that needs to be read once or can\u2019t be categorised with any other property. In this case, you can use the @Value annotation to read it.<\/li>\n
- Reading a set of properties<\/strong> \u2013 In our example, we have already identified two grouped properties under the \u201cbungie\u201d category. This is how I prefer to create properties. I do not like having orphan properties, and hence we will only see how to set these up. The following example will show us creating a Java Bean\/Configuration, which will be able to read our property file and populate the object.<\/li>\n<\/ul>\n
package io.howtoarchitect.destinyclanwars.config;\n\nimport lombok.Getter;\nimport lombok.Setter;\nimport org.springframework.boot.context.properties.ConfigurationProperties;\nimport org.springframework.context.annotation.Configuration;\n\n@Configuration\n@ConfigurationProperties(\"bungie\")\n@Getter @Setter\npublic class BungieClientSettings {\n private String rootPath;\n private String apiKey;\n}<\/pre>\nIf you observe the code block above, you will notice a few things:<\/p>\n
\n
- We have used
@Configuration<\/code> to let the Spring application know that this is a bean and should be initialised as such<\/li>\n@Getter<\/code> and@Setter<\/code> are from the Lombok package, giving us default Getters and Setters. These are mandatory as Spring application will always need these getters and setters.<\/li>\n@ConfigurationProperties<\/code> is the annotation that does the main trick here. It will go through all the properties available in our context and will search for any that have been mapped user \u201cbungie\u201d. Once found, this annotation will map the YAML\/Properties file values and add them to our strings.<\/li>\n<\/ul>\n5. Consuming Properties<\/h2>\n
Once you have this setup, the last step is to read these properties in our application. We will be reading these properties in another Spring bean\/service.<\/p>\n
package io.howtoarchitect.destinyclanwars.bungieclient;\n\nimport io.howtoarchitect.destinyclanwars.config.BungieClientSettings;\nimport org.springframework.beans.factory.annotation.Autowired;\nimport org.springframework.http.HttpHeaders;\nimport org.springframework.http.MediaType;\nimport org.springframework.stereotype.Service;\nimport org.springframework.web.reactive.function.client.WebClient;\n\n@Service\npublic class BungieClient {\n private static WebClient client;\n\n @Autowired\n private BungieClientSettings bungieClientSettings;\n\n public WebClient getDefaultClient() {\n client = WebClient.builder()\n .baseUrl(bungieClientSettings.getRootPath())\n .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)\n .defaultHeader(\"X-API-KEY\", bungieClientSettings.getApiKey())\n .build();\n\n return client;\n }\n}<\/pre>\nYou will notice that I have added
BungieClientSettings<\/code> as an@Autowired<\/code> dependency. This injects the bean in my class, and when I need to access these properties, all I need to do isbungieClientSettings.getAPIKey()<\/code> andbungieClientSettings.getRootPath()<\/code>.<\/p>\nConclusion<\/h2>\n
This is all you need to do is to externalise your properties. This is important to set up early on because if you do not, you will end up having many of these scattered in classes, and moving across to multiple environments will become hard.<\/p>\n
In next few articles, we will look at<\/p>\n
\n
- How to use environment-based configuration. In my case, I will have different keys for development and production, and I will be able to handle the same.<\/li>\n
- Use Spring\u2019s cloud configuration Server, which will allow us to centralise our configurations into 1 project and also be able to swap designs without having to deploy the code (Configuration as Code pattern).<\/li>\n
- Finally, we will look at how can we secure some of these properties via encryption. For example, my
apiKeys<\/code> need to be confirmed. I have used random values in the samples that I have given, but in my application, I need keys to be valid and not exposed via GITHUB repo plain text files.<\/li>\n<\/ol>\n\n