Few open-source projects can claim to have had a similar impact on their domain like the Spring framework had on Java. Not only did it have a major influence on the guiding principles of the second version of the EJB standard, it also became the de-facto standard for Java-based enterprise applications in no time. Fast forward to today, Spring and related are still going strong and positioned as dominant as ever. A recent market analysis conducted by RedMonk based on data from github and stackoverflow indicate that Java is still (by far) the most used language in the enterprise world and that the adoption of Spring is not decreasing – the opposite (see Java for Cloud Natives by James Governor)
The ones I mentioned explicitly are two that get a lot of traction lately, especially in the whole context of “cloud native” application development, hence I believe it would be worthwhile to cover them in more detail. I wrote about the former a while ago already (see: Released: Spring Cloud Connectors for HCP), so starting with today’s post I want to kick off a new series of blog posts about the later: Spring Boot.
In its own words, Spring Boot takes:
[…] an opinionated view of building production-ready Spring applications. Spring Boot favors convention over configuration and is designed to get you up and running as quickly as possible.
So, it’s not really something completely new, but maybe something that can be summarized as an alternative way to develop Spring applications that aims to speed up the development. In addition, it also lowers the entry barrier as it simplifies some of the dependency management that may be overwhelming to newbies. Given the sole value proposition of cloud applications are reduced time to market agility and lower costs of development it sounds to be a great fit, right?
Spring Boot in a nutshell
From a technical perspective Spring Boot differs from classic Spring in several ways, e.g. how it handles configuration and dependency management. Furthermore, during the build process Spring Boot embeds a servlet container (such as Tomcat, Jetty or Undertow) directly into an executable
JAR instead of creating a
WAR file that needs to be explicitly deployed to a runtime environment. This way one can simply execute the web application locally without having to bootstrap a servlet container or the like.
Spring Boot and SAP HANA Cloud Platform
This different bundling concept (for the lack of a better word) may be the biggest challenge for someone trying to get a Spring Boot app running on SAP HANA Cloud Platform. As you probably know, SAP HANA Cloud Platform offers various runtimes (see Application Runtime Container) such as Tomcat 7 or Tomcat 8. What they all have in common though is that they can only handle classic
WAR files as deployment units. So in simple terms, we need to Spring Boot to generate a
WAR file without an embedded servlet container in order to be able to deploy it.
In simple terms, it boils down to a few changes in the
pom.xml file to come up with a good old
WAR file to deploy.
One more thing
As outlined in the official online documentation the assembled
WAR file MUST not include any
SLF4J related jar files, hence we need to omit the bundling of the
spring-boot-starter-logging dependency as well.
As a reference, I’ve created a simple sample that illustrates all of the above. We’ll take it as a baseline for the upcoming posts of the series. Stay tuned!
UPDATE: Part 2 of this series can be found here: Getting started with Spring Boot – Part 2
Github repository: https://github.com/SAP/cloud-spring-boot-sample