Most Spring users are familiar with Spring Boot, and at Broadleaf, we’re in the middle of developing our own support for this new framework. Spring Boot is a project that attempts to provide a streamlined view of configuration and runtime behavior for Spring framework based applications. A developer can create an application and have something up and running with minimal effort (sometimes with as little as a maven pom.xml and a single Java class launch point). This minimal amount of configuration noise is achievable because of the “opinionated” methodology taken by Spring Boot.

By including “starters” on the classpath, Spring Boot can, and will, configure a number of working services for your application that would otherwise require a laundry list of boilerplate code and xml. For example, with the right starters, Spring Boot will auto-configure and launch JPA support, backed by Hibernate, targeting an in-memory database. Granted, using an in-memory database would not be suitable for production, but it is an acceptable starting point when you want to prototype an idea quickly. Additionally, Spring Boot makes it easy to back off from this auto configuration when it makes sense. For example, by declaring your own data source configuration, Spring Boot understands you now want to take over that layer of the application and it will no longer attempt to own it.

Another interesting aspect of Spring Boot is the executable product it is capable of emitting. For the most part in Java, we are accustomed to creating WAR or EAR files that we upload to a container (e.g. Tomcat). The container provides the appropriate classloader behavior, http(s) request management, and many times, the datasource connection management. More advanced containers provide an extensive list of additional, and possibly useful services. However, these services tend to go unused in many Spring-based applications, since the Spring framework is so apt at providing most or all of the advanced application functionality in its own ecosystem.

With Spring Boot, we can take the idea of the WAR application file, and the associated container, a step further. Rather than emit a web-ready WAR file, we can emit an executable archive that is capable of launching an internal, lightweight, production-ready container (i.e. Tomcat, or Jetty) running the application. When it makes sense, this concept can extend to launching other services as well (database and Solr support come to mind). This type of approach can make it very easy to deploy a complete, or near complete, solution over any number of nodes in a standard infrastructure. This type of approach resonates nicely with system administrators as they strive to automate and “containerize” their infrastructures.

At Broadleaf Commerce, we’re in the middle of developing our own support for Spring Boot and we’re very excited to share some of the early headlines:

  • We’re finally removing our xml app context merge process
  • Java-based configuration (rather than xml) is a first-class citizen
  • Advanced merge support via annotation in Java configuration
  • Executable build output (launch your Broadleaf implementation with embedded Tomcat and other services with a single command)
  • The Spring Boot application configuration file approach is supported - no need to use a proprietary Broadleaf format
  • Easy Broadleaf module configuration with intelligent defaults
  • Minimal configuration yielding real results
  • Faster restarts using boot devtools

We’ve already had a relatively opinionated view of running Broadleaf in our reference implementation (e.g. MySQL, Thymeleaf, Solr), which we ship as a suggested starting point to our users. However, getting a basic instance of the reference implementation up and running has sometime involved more configuration than we would like, especially when a custom list of Broadleaf modules are involved. With Spring Boot, and a nice set of Broadleaf application and module starters, we will be able to greatly simplify this configuration and enable our users to be more productive faster and with less headaches.

As a teaser, I want to show a preview of some working code we have for launching our admin application, with container and database support, inside Spring Boot. I mentioned earlier that configuration for a Spring Boot application can be as little as a pom.xml file and a Java starting point. This remains true for a Broadleaf application based on Spring Boot.

Pom.xml -

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="" xmlns:xsi=""
 </project><span class="redactor-invisible-space">
</span> -

@EnableAutoConfiguration(exclude = {ThymeleafAutoConfiguration.<b>class</b>, 
DispatcherServletAutoConfiguration.<b>class</b>, WebMvcAutoConfiguration.<b>class</b>})
<b>public class </b>Example {
    <b>public static void </b>main(String[] args) <b>throws </b>Exception {
     SpringApplication.<i>run</i>(Example.<b>class</b>, args);

That's it! The pom.xml declares the appropriate starter dependencies and the class serves as the launch point into Spring Boot. With these two files and the following command, we have a full working version of the 5.0 Broadleaf admin running locally.

mvn spring-boot:run -Drun.jvmArguments="-javaagent:/[path to spring instrument jar]"

Stay tuned for more information, as we look to wrap up the functionality and roll it out in the next several months.