Spring boot (profiles)

Background

I’m pretty new to the spring ‘scene’.  I did Java work out of college for quite awhile, even working on J++ (anyone remember that?) for a few years until moving companies and transitioning to C#/.net for a full 10 years.  I’ve always been interested and motivated by the open source community and the work that goes into these projects, but .net hasn’t historically lent itself to this community (I do have to say, MS does seem to be changing things a little bit here recently).

However, this all changed at the end of 2013.  I was (luckily) involved in a project at work that utilized Spring to reboot our group to have more java in the mix.  Alongside java was linux as the development environment.

The Experience

Just like with any new technology stack, spring felt fairly overwhelming.  The java world had matured a LOT since I was last involved with it – spring was very deep and pretty confusing, but I could see that the spring team was solving very common enterprise problems with very strong design patterns.  I WANTED to learn more about spring, I WANTED to learn more about Java and the current state of the language.

What followed was a few months of picking up lots of things to get current on the language, Maven, and Spring itself.  I realized that it was VERY difficult to even START a spring application and there was lots of confusing documentation out there that used both XML and Java Configurations and it was hard to find the right information at the right time.

That’s where Spring Boot stepped in.

Spring Boot

Spring Boot has felt like a breathe of fresh air to me.  It’s focused Spring itself on an ‘opinionated’ stack (i.e. choices made for you for common scenarios) while still allowing overrides for those opinions in order to solve specific issues or decisions you have made or just plain prefer (i.e. want to use log4j instead of logback?  no problem, just add it to your classpath.  want to use Eclipse Link instead of Hibernate?  spring boot has you covered).

My first test of spring boot was to try to to write a simple application that used multiple databases.  The scenario was multiple Profiles, minimally 1 for dev and 1 for production.  I wanted to see how Spring Boot would allow me to seamlessly switch between profiles and how quick and effortlessly (or not) this would be, so I created a simple application at https://github.com/jimbasilio/SpringBoot-profiles.

While profiles may not be the sexiest topic, it’s one that is pretty important when developing an application in order to be able to quickly transition from your dev environment to your production environment (with ideally a test environment to boot). In the spring docs it has a section devoted to profiles.

The Spring Boot Documents (1.1.0) are a GREAT source of information and pointers to example projects from the Spring team itself, but sometimes they don’t go deep enough. For my test project I added both h2 and hsqldb to my classpath via my pom.xml file.

hsqldb and h2

This pulls both databases in for access via spring, which you can then specify settings in your application*.properties files to decide what you want to use, and more importantly when. In order to specify the ‘when’ for using different databases you simply need to pass an argument to spring boot via the JVM parameters:

After some experience at work, I realized that choosing profile definitions based on environment (i.e. dev or prod) is not a good idea. It’s too inflexible. Instead, creating profiles for each segment of your app that you want to pull in is preferred.

For example, if you have multiple databases to support, define a profile for each (application-hsql.profile, application-h2.profile). This way you are able to shuffle in different features to test without having to dictate what a ‘production’ environment is. Instead, define your production environment based on the profiles you need to use and put these on the commandline that you will run in production.

Another example is if you want an awesome feature on at TIMES, but by default this feature can be off. When you include the properties definition you can default it to false:

awesome feature disabled

But when you are ready to turn this feature on you can simply put it on your commandline and it’ll pull in the properties file and turn it on:

with awesome feature

When you add the ‘awesomefeature’ to the commandline and visit the controller you’ll see the proper text indicating the feature is active.

awesome feature browser

Summary

So in summary, spring boot is great for getting off the ground QUICKLY with all the goodness that spring provides. It allows you to hook in and dictate the behavior you want (not discussed in this blog) and also has the ability to select ‘profiles’ that can be used for all sorts of useful combinations of features when testing and building to production.

Hope you enjoyed reading!