Expand Authors Top

If you have a few years of experience in the Java ecosystem and you’d like to share that with the community, have a look at our Contribution Guidelines.

Expanded Audience – Frontegg – Security (partner)
announcement - icon User management is very complex, when implemented properly. No surprise here.

Not having to roll all of that out manually, but instead integrating a mature, fully-fledged solution - yeah, that makes a lot of sense.
That's basically what Frontegg is - User Management for your application. It's focused on making your app scalable, secure and enjoyable for your users.
From signup to authentication, it supports simple scenarios all the way to complex and custom application logic.

Have a look:

>> Elegant User Management, Tailor-made for B2B SaaS

NPI – Spring Top – Temp – Non-Geo (Lightrun)

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

>> LEARN SPRING
NPI – Lightrun – Spring (partner)

We rely on other people’s code in our own work. Every day. It might be the language you’re writing in, the framework you’re building on, or some esoteric piece of software that does one thing so well you never found the need to implement it yourself.

The problem is, of course, when things fall apart in production - debugging the implementation of a 3rd party library you have no intimate knowledge of is, to say the least, tricky. It’s difficult to understand what talks to what and, specifically, which part of the underlying library is at fault.

Lightrun is a new kind of debugger.

It's one geared specifically towards real-life production environments. Using Lightrun, you can drill down into running applications, including 3rd party dependencies, with real-time logs, snapshots, and metrics. No hotfixes, redeployments, or restarts required.

Learn more in this quick, 5-minute Lightrun tutorial:

>> The Essential List of Spring Boot Annotations and Their Use Cases

1. Introduction

YAML is a human-friendly notation used in configuration files. Why would we prefer this data serialization over the properties file in Spring Boot? Besides readability and reduction of repetition, YAML is the perfect language to write Configuration as Code for the deployments.

In the same way, the use of YAML for Spring DevOps facilitates the storage of the configuration variables in the environment as the 12 Factor Authenticator recommends.

In this tutorial, we'll compare Spring YAML versus properties file in order to check the main advantages of using one over the other. But remember, the selection of YAML over properties file configuration is sometimes a decision of personal taste.

2. YAML Notation

YAML stands for a recursive acronym for “YAML Ain't Markup Language“. It provides the following characteristics:

  • More clarity and human-friendliness
  • Perfect for hierarchical configuration data
  • It supports enhance capabilities such as maps, lists, and scalar types

Those capabilities make YAML the perfect companion for Spring configuration files.  A word of caution here for those starting out with YAML: writing it can be a bit tedious at the beginning due to its indentation rules.

Let's see how it works!

3. Spring YAML Configuration

As it was mentioned in the previous sections, YAML is an extraordinary data format for configuration files. It's much more readable, and it provides enhanced capabilities over the properties file. Therefore, it makes sense to recommend this notation over the properties file configuration. Furthermore, from version 1.2, YAML is a superset of JSON.

In addition, in Spring the configuration files placed outside the artifact override those inside the packaged jar. Another interesting feature of Spring configuration is the possibility to assign environment variables at runtime. This is extremely important for DevOps deployments.

Spring profiles allow separating the environments and apply different properties to them. YAML adds the possibility to include several profiles in the same file.

Note: this feature is also supported for properties files with Spring Boot 2.4.0.

In our case, for deployment purposes, we'll have three: testing, development, and production:

spring:
  profiles:
    active:
    - test

---

spring:
  config:
    activate:
      on-profile: test
name: test-YAML
environment: testing
servers:
  - www.abc.test.com
  - www.xyz.test.com
  
---

spring:
  config:
    activate:
      on-profile: prod
name: prod-YAML
environment: production
servers:
  - www.abc.com
  - www.xyz.com
    
---

spring:
  config:
    activate:
      on-profile: dev
name: ${DEV_NAME:dev-YAML}
environment: development
servers:
  - www.abc.dev.com
  - www.xyz.dev.com

Note: if we use a Spring Boot version prior to 2.4.0, we should use the spring.profiles property instead of the spring.config.activate.on-profile we used here.

Let's now check the spring.profiles.active property which assigns the test environment by default. We can redeploy the artifact using different profiles without building again the source code.

Another interesting feature in Spring is that you can enable the profile via the environment variable:

export SPRING_PROFILES_ACTIVE=dev

We'll see the relevance of this environment variable in the Testing section. Finally, we can configure YAML properties assigning directly the value from the environment:

name: ${DEV_NAME:dev-YAML}

We can see that if no environment variable is configured, a default value dev-YAML is used.

4. Reduction of Repetition and Readability

The hierarchical structure of YAML provides ways of reducing the upper levels of the configuration properties file. Let's see the differences with an example:

component:
  idm:
    url: myurl
    user: user
    password: password
    description: >
      this should be a long 
      description
  service:
    url: myurlservice
    token: token
    description: >
      this should be another long 
      description

The same configuration would become redundant using properties file:

component.idm.url=myurl
component.idm.user=user
component.idm.password=password
component.idm.description=this should be a long \
                          description
component.service.url=myurlservice
component.service.token=token
component.service.description=this should be another long \ 
                              description

The hierarchical nature of YAML greatly enhances legibility. It is not only a question of avoiding repetitions but also the indentation, well used, perfectly describes what the configuration is about and what is for. With YAML, as in the case of properties file with a backslash \, it is possible to break the content into multiple lines with > character.

5. Lists and Maps

We can configure lists and maps using YAML and properties file.

There are two ways to assign values and store them in a list:

servers:
  - www.abc.test.com
  - www.xyz.test.com
  
external: [www.abc.test.com, www.xyz.test.com]

Both examples provide the same result. The equivalent configuration using properties file would be more difficult to read:

servers[0]=www.abc.test.com
servers[1]=www.xyz.test.com

external=www.abc.test.com, www.xyz.test.com

Again YAML version is more human-readable and clear.

In the same way, we can configure maps:

map:
  firstkey: key1
  secondkey: key2

6. Testing

Now, let's check if everything is working as expected. If we check the logging of the application, we can see that the environment selected by default is testing:

2020-06-11 13:58:28.846  INFO 10720 --- [main] com.baeldung.yaml.MyApplication: ...
using environment:testing
name:test-YAML
servers:[www.abc.test.com, www.xyz.test.com]
external:[www.abc.test.com, www.xyz.test.com]
map:{firstkey=key1, secondkey=key2}
Idm:
   Url: myurl
   User: user
   Password: password
   Description: this should be a long description

Service:
   Url: myurlservice
   Token: token
   Description: this should be another long description

We can overwrite the name by configuring DEV_NAME in the environment:

export DEV_NAME=new-dev-YAML

We can see that the name of the environment changes executing the application with dev profile:

2020-06-11 17:00:45.459  INFO 19636 --- [main] com.baeldung.yaml.MyApplication: ...
using environment:development
name:new-dev-YAML
servers:[www.abc.dev.com, www.xyz.dev.com]

Let's run for the production environment using SPRING_PROFILES_ACTIVE=prod:

export SPRING_PROFILES_ACTIVE=prod

2020-06-11 17:03:33.074  INFO 20716 --- [main] ...
using environment:production
name:prod-YAML
servers:[www.abc.com, www.xyz.com]

7. Conclusion

In this tutorial, we described the intricacies of the use of YAML configuration compared to the properties file.

We showed that YAML provides human friendliness capabilities, it reduces repetition and is more concise than its properties file variant.

As always, the code 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!