Configuring embedded Tomcat - Spring Boot Tutorial

- [Instructor] One of the biggest concerns that many organizations have when moving to Spring Boot is how do they configure the servlet container that their application is running in? Many of them have specific requirements on how communications are to operate over a web-enabled network. And as such, configuring Tomcat is critical when moving to the Spring Boot world. Now, one of the areas that you can configure is in the servlets, filters, and listeners. Now, by default, Spring Boot will give you a servlet that responds at the context route and is autoconfigured with many of the defaults that we have come to love, at least those of us who use Spring Boot a lot. That being said, if you want to add your own servlets, your own filters or your own listeners, there's a very simple way to do that. That way is to configure the servlets, filters, and listeners as beings. Now, you can do that in two very easy ways. The first is to go into one of your configuration classes and annotate a method with @Bean that serves one of these objects. The other way is to annotate the actual class file with @WebServlet, @WebFilter, or @WebListener, and allow it to be component-scanned and put into the embedded container. And this is a great time for me to mention that in Spring Boot applications, at least a web-enabled one, you actually have several application contexts, one of which is specific to the embedded Tomcat itself. Spring Boot knows that these types of objects, servlets, filters, and listeners belong in the embedded container. In addition, if you want to create a servlet context, you can do that using the ServletContext initializer. But none of this is very common other than the filters used for security purposes, and there's a much better way to do that with Spring Security. The easiest way to configure your embedded Tomcat is through the use of properties. And indeed, we've already been doing that through the server.port property. There's lots of them dealing with the server itself, such as the address that's bound to the port, the default contextPath. But you also have access to the way that session is managed through cookies, timeouts, and persistence of those sessions. All of that can be configured through properties. The default error page, and I'm not talking about the web error page, the server error page can also be configured through properties. Now, a full list of these properties is actually in the code. If you go to org.springframework.boot .autoconfigure.web.ServerProperties, that class is a placeholder for all of these properties files, and you can take a look at them and see what you can modify. An important thing to note while I'm talking about this, all of these autoconfigurations exist; you just sometimes have to look for them to look at the full list of properties that are available. Now, compression is another very common thing that people want to modify on a default Spring Boot application. You can very easily turn compression on by using the server.compression.enabled property and set its value to true. Now, by default, all response types that are 2048 bytes or more will be compressed if this property is set to true. But you can modify that threshold based on yet another property. Also, by default, there are four mime types that will be compressed if they exceed this limit: text/html, text/xml, text/plain, and text/CSS are the default mime types to be compressed. If you want to compress other ones, you guessed it, there's a property for that as well. Now, by and large, the single most common way to change the embedded servlet container is to migrate it from standard HTTP to a TLS flavor. This is actually a requirement, and should be for many shops, for all web traffic to leverage TLS. At this point in time, everything should be encrypted over the internet. Now, there's native support via a property management. And as I said, this is the most common embedded servlet change that you'll probably experience. Now, one thing to note, this requires a keystore be available to your application, which makes sense 'cause TLS is based on keystores. This also means that a password for that keystore needs to be available to your application via properties. So if you don't have something like a secret manager that connects to your runtime used for storing all your credentials, any developer that has access to your source control management potentially has access to all of the contents of the keystore. The Spring website has a lot of demos around these topics and very good documentation. So if these fit your needs, I suggest you dig in there.