OK, so everybody loves the Spring Framework right?!
And we are so used to the features that Spring provides out of the box such as dependency injection, transaction management, messaging support, integration support, aspect support and the list continues. Name a necessity and you will find a Spring library that has been built around it to cater to your needs. Of course, these packages or modules within the Spring ecosystem provide a framework level support that makes a lot of headway into the actual application development process.
Behind all the goodness, we as Java™ developers know that it is a framework that often eludes the most seasoned developers. As a framework, it becomes so overwhelming at times, that even to understand how to fit a particular Spring module will makes some developers comment “I could have written the code myself, rather than configuring it“.
As a developer, I have seen legacy Spring projects, where even something like Maven or Gradle had not been used for dependency management. So that brings another set of “ToDos” to the table. As if the XML and Bean configurations were not enough, one should now deal with dependency conflicts and version mismatch of the various library packages as well.
Spring Boot to the Rescue
For developing enterprise Java applications, most of us will have to use Spring at some point of time. But it has also traditionally been known to induce a lot of framework overhead of configuration and change management. But don’t you worry, here comes “Spring Boot” to the rescue.
If you look at the project page of Spring Boot, it reads something like:
Spring Boot makes it easy to create stand-alone, production-grade Spring based applications that you can ‘just run’.
So, what does that mean?
‘easy’: The point easy comes from the idea that a lot of “starter-poms” have already been pre-configured for you.
Which basically means: “Tell Boot what you want, and it will configure the dependencies for you”.
In the image below, I have shown an STS screenshot for a new spring project that I want to build.
In this example I have selected only two dependencies
- Mongo DB
The definition of Web is “Full stack application development using tomcat and MVC support“.
And the definition Mongo DB is, well configure Mongodb dependencies… And that’s it.
Now let us have a look at the pom that has been generated as a result of the above selection.
A pre-configured pom.xml with only 2 dependency entries has been generated. One dependency is called ‘spring-boot-starter-web‘ and the other ‘spring-boot-starter-data-mongodb‘.
Let us see the screenshot of the pom below.
Now let’s see what is the effective dependency hierarchy that has been generated as a result.
Here we see that the dependency requirements have already been configured in my application. This is a handy feature of the ‘starter pom(s)‘ that lets you configure your application dependencies out of the box.
‘stand-alone’: Most of the traditional web applications have been developed to run within an application server.
One nice feature about any ‘Spring Boot’ application is that you can run your application in a traditional J2EE server, or if you choose, you can run it as a self-contained archive as well.
java -jar ...... <your archive file>
There will be no difference in how the end-user interacts with the application.
‘just run’: Any Spring Boot application can be run like a java application that runs from a main method.
Most of the dependencies will be auto-configured for you. You can read the Javadocs for @SpringBootApplication here.
So where have the project specific configuration parameters gone?
They are just there, in an “application*.properties” file or “application*.yml” file in the classpath. Here you can provide your environment specific project settings such as jdbc url , smtp hostnames etc. For the actual values of the parameters, you can refer to the official documentation present here.
‘profiles’: You write your configuration settings only once in your application*.properties file or application*.yml, and take the same build across various environments such as development, testing and production.
But what about the changes in configuration parameters such as database connection urls or smtp hostnames? This is where the concept of profiles come in handy. Let’s say I have a ‘dev‘ environment and a ‘prod‘ environment.
So, I might have the below configuration files that take care of my environment specific settings.
- application.yml (The default profile when nothing has been specified explicitly while running the application)
- application-dev.yml (This file will have the configurations for my ‘dev’ profile)
- application-prodI.yml (This file will have the configurations for my ‘prod’ profile)
While running the application, I can specify which profile I want to run and the same will be picked up while bootstrapping the application.
In my opinion, Sping Boot is one of the best things that could have happened within the Spring community and it makes the set up and configuration of Spring applications a breeze. The learning curve is small compared to the huge amount benefits that it provides. If you are developing a new Spring application, give it a try! I’m pretty sure you will enjoy it…
Learn more about Java programming and Spring on developerWorks
- Java development on developerWorks
- Spring Boot basics
- Intro to Java programming
- The top five reasons you should be using JUnit 5 right now!