Mocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Explore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely — and automatically — with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.
Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.
In this tutorial, we'll focus on Dapr's pub/sub API for message brokering. Using its Spring Boot integration, we'll simplify the creation of a loosely coupled, portable, and easily testable pub/sub messaging system:
1. Overview
In this quick article, we’ll discuss deploying a web application at the root of a Tomcat.
2. Tomcat Deployment Basics and Terminology
First, the basics of deploying an application to Tomcat can be found in this guide: How to Deploy a WAR File to Tomcat.
Simply put, web applications are placed under $CATALINA_HOME\webapps, where $CATALINA_HOME is the Tomcat’s installation directory.
The context path refers to the location relative to the server’s address which represents the name of the web application.
By default, Tomcat derives it from the name of the deployed war-file. So if we deploy a file ExampleApp.war, it will be available at http://localhost:8080/ExampleApp. I. e. the context path is /ExampleApp.
If we now need to have that app available at http://localhost:8080/ instead, we have a few options, which we’ll discuss in the following sections.
For a more detailed explanation of the context concept of Tomcat, have a look at the official Tomcat documentation.
3. Deploying the App as ROOT.war
The first option is very straightforward: we just have to delete the default /ROOT/ folder in $CATALINA_HOME\webapps, rename our ExampleApp.war to ROOT.war, and deploy it.
Our app will now be available at http://localhost:8080/.
4. Specifying the Context Path in the server.xml
The second option is to set the context path of the application in the server.xml (which is located at $CATALINA_HOME\conf).
We must insert the following inside the <Host> tag for that:
<Context path="" docBase="ExampleApp"></Context>Note: defining the context path manually has the side effect that the application is deployed twice by default: at http://localhost:8080/ExampleApp/ as well as at http://localhost:8080/.
To prevent this, we have to set autoDeploy=”false” and deployOnStartup=”false” in the <Host> tag:
<Host name="localhost" appBase="webapps" unpackWARs="true"
autoDeploy="false" deployOnStartup="false">
<Context path="" docBase="ExampleApp"></Context>
<!-- Further settings for localhost -->
</Host>Important: this option is not recommended anymore, since Tomcat 5: it makes context configurations more invasive, since the server.xml file cannot be reloaded without restarting Tomcat.
5. Specifying the Context Path in an App-Specific XML File
To avoid this problem with the server.xml, we’ve got the third option: we’ll set the context path in an application-specific XML file.
Therefore, we have to create a ROOT.xml at $CATALINA_HOME\conf\Catalina\localhost with the following content:
<Context docBase="../deploy/ExampleApp.war"/>Two points are worth nothing here.
First, we don’t have to specify the path explicitly as in the previous option – Tomcat derives that from the name of our ROOT.xml.
And second – since we’re defining our context in a different file than the server.xml, our docBase has to be outside of $CATALINA_HOME\webApps.
6. Conclusion
In this tutorial, we discussed different options of how to deploy a web application at the root of a Tomcat.
