Spring has become a highly popular framework for the development of web applications, thanks to a compelling support for web features, both at its core and within extensions modules. When it comes to deployment time, Spring shines again by its container agnosticism. Because Spring web applications are pretty much self contained, they can get deployed on any JavaEE container. With a plethora of containers available, picking one can be a daunting task.
As you may know already, MuleSoft Tcat Server is a plain vanilla Apache Tomcat enriched with management web applications in order to deliver state-of-the-art application provisioning, configuration management and monitoring capabilities.
In this post, we’ll look at two scenarios where deploying on Tcat can help you to go further with your Spring web applications. For this, we will leverage Tcat’s configuration profile mechanism that, among other things, allows an orderly deployment of files anywhere within a Tomcat’s directory hierarchy.
Configuring Properties
If your company is still doing manual deployments of its applications, it is more than likely that a deployment request for pushing a new release to 20 servers will end-up as depicted in this highly technical diagram:
This black duck is the one server that didn’t get configured properly: after 19 potentially tedious manual deployments and configuration operations, the ops team was getting tired and something got forgotten. To make things worse, ill configured servers can be hard to find and may introduce unexpected behavior in an application cluster.
Tcat’s configuration management features help resolving this kind of issues by automating the deployment of applications and their configuration files too. As far as Spring is concerned, this means that Tcat can be used to manage and deploy the properties files that are used to configure web applications (Java system properties can be used too and can also be configured by Tcat).
As shown above, a common scenario consists in having:
- A common properties file with entries relevant to the development environment checked in source control and used by developers,
- An environment specific file containing local overrides for some of the properties (like, for example, database connection information).
Putting this configuration hierarchy in place is trivial with Spring, as the following configuration sample shows it:
When building our Spring web application, we will need to embed spring-webapp-default.properties as a classpath resource. Because, we’re instructing Spring to ignore the resources that are not found, this application will be able to run as is. If, in an environment, we place on the classpath a file named spring-webapp-override.properties, the values from this file will be loaded by Spring and will override the ones found in the embedded file.
So how do we place such an overriding file on the classpath with Tcat? Being a standard Tomcat, we can decide to drop the file in any well known location that is on the classpath, like the /lib directory. Because we prefix our overriding file with the application name, there is no risk of collision with other applications.
We simply need to create a profile repository structure that mimics the one found within Tomcat and place there the file we want to deploy, as shown hereafter:
Applying this profile to a single server or a group thereof is couple of clicks away. Once done, all the designated servers will have the override file in place and will be correctly configured. No more hassle with half-configured environments!
Let’s now look into another neat Spring feature that works particularly well with Tcat.
Refreshing Beans
Spring’s refreshable beans offer the possibility to hot deploy new business logic without any downtime. This can be extremely powerful but bears the complexity that is inherent to delta releases. In truth, delta releases are treacherous and most of the time a bad idea because it is very easy to end-up with a messy situation where it’s almost impossible to figure out exactly what is deployed where.
Again, by using Tcat’s profile mechanism, we can alleviate the issue with delta deployments and reap the full benefits of Spring’s refreshable beans. Let’s see how.
First, we need the Spring bean we want to be able to refresh. It is typically defined by an interface:
and implemented with a dynamic language, like Groovy:
Spring provides the configuration mechanism in its lang namespace. The following loads the above Groovy script as a bean and checks if it needs to be refreshed every 5 seconds:
Now suppose that a change in the above shipping prices is needed in production: it is trivial to use the previously shown Tcat profile mechanism to perform an automatic and systematic deployment of the new Groovy-backed bean to all the servers running the target web application.
For this, we reproduce the web application structure in Tcat’s repository for our production profile, as shown hereafter:
Applying this profile to the target server or server group will trigger a refresh of the Groovy bean and, within 5 seconds, a change of business logic without any downtime.
Probing Further
If you want to explore further how Tcat can help you better handle your Spring web application, visit Tcat’s resources page: you’ll find a download link there and all the information you need.
Happy Springing into Tcat!
