Spring Boot WebMvc

When we are working on traditional spring webmvc applications, we package our application as a war file and deploy it on the standalone servlet container or on an application server. But while working with spring boot in building webmvc application we dont package our application as a war file, rather we package our application as an boot executable jar and run the application straight out of the main() method itself as an standalone application without deploying on the servlet container.

When we run our spring boot mvc application out of a jar file, using the main() method, internally spring boot takes care of deploying our application on the embedded servlet container and run our application inside it.

What is embedded servlet containers, what is the purpose of them?

Instead of downloading, installing and configuring the standalone servlet containers, the container vendors shipped the containers as jar libraries or dependencies out of their codebase itself. These embedded servlet container libraries can be added to the classpath/buildpath of our application, so that the containers are part of the code and can be run through our application code itself that doesnt require any explicit installing/configurations. There are lot of advantages of using embedded servlet containers in running the application.

When we are developing spring boot webmvc application we need to add spring-boot-starter-webmvc as an dependency in our project. Upon adding webmvc boot starter as a dependency, it transitively adds the embedded servlet container into our project. By default the spring-boot-starter-webmvc pulls the embedded tomcat server as an transitive dependency and adds to our project.

We dont need to write any code for registering, deploying and running our application on the embedded servlet container, upon calling SpringApplication.run(BootApplication.class, args) it takes care of internally deploying and running our application on the embedded servlet container.

Spring boot supports 4 embedded servlet containers currently

1. tomcat (default)

2. jetty

3. undertow

4. netty (reactive stack) (spring webflux)

Inorder to understand how does spring boot internally takes care of deploying and running the webmvc application on the servlet container, let us explore ourself in building an web application and running on the embedded servlet container out of a main method.

Representing the context root of our application we need to create an StandardContext object in the tomcat server as below.

Tomcat tomcat = new Tomcat(8080);

StandardContext context = (StandardContext) tomcat.addWebApp("/travelgo", new File("src/main/webapp").getAbsolutePath());

With this we added an WebApplication into the tomcat server register with the contextroot as "/travelgo", now to this application we need to define directory set of resources like ROOT directory, CLASSES dir etc

WebResourceRoot directory = new StandardRoot(context);

What are the advantages of using embedded servlet containers?

The embedded servlet containers are nothing but, the server vendors aspart of the sourcecode of the servers, they build, package and distribute the servers as libraries. So that these can be included as dependencies in our project and use them.

advantages:-

1. The containers are shipped aspart of the code itself, so we dont need to download, install and configure them to use.

2. In an traditional application deployments, we need to manually perform necessary configurations required ontop of the container to deploy the applications like

1. connection pool configurations

2. jms resources

3. security

etc

unless these resources or configurations are applied on the containers, we cannot deploy the application. since these configurations are performed manually on the servers, it could lead to

1. human errors

2. lot of time needed for performing these configurations

3. should be applied repeatedly across the envs 

whereas while working with embedded containers, since the servers are shipped aspart of the code, the configurations required to be applied on these servers are also driven through code itself, due to which we can avoid manually configurations on the server that eliminates all the problems above.

3. easy to adopt ci/cd of an application 

While adopting the ci/cd pipeline, we need to write lot of code in building and running the application on the target environment.

upon provisioning the infrastructure, the devops engineers has to write the code using software configuration management tools like ansible, puppet or chef etc for installing and configuring the application servers/servlet containers on the target environment. Along with that they need to take care of patching, upgrading, backup/restore of these server environments regularly.

This is an laborious process and takes huge amount of time for adopting and implementing the pipeline automation

4. The Embedded servlet containers fully supports development and delivery of microservices based applications.

In a microservice based application, each microservice should be build out of its own sourcecode, as an independent project, that should be loosely-coupled and independently deployable (each microservice should be running in its own container).