Spring Boot Jar vs War: Understanding the Real Differences

Why a JAR Cannot Run Inside an External Tomcat

Spring Boot’s executable JAR bundles an embedded Tomcat (included via spring-boot-starter-web) and the Maven Spring Boot plugin repackages the application, its dependencies, and the starter into a single runnable JAR. When you execute java -jar demo.jar, the JVM starts Spring Boot’s own startup process, creates the application context, and launches the embedded servlet container. Configuration in application.yml (e.g., server.port and server.servlet.context-path) directly controls this container.

java -jar demo.jar

Why server.port Is Ignored When Deploying a WAR

A WAR is a traditional servlet archive. It does not start Tomcat; instead, an external Tomcat instance loads the WAR from its webapps directory, creates a servlet context, and forwards requests to the Spring application. The port is determined by Tomcat’s own configuration file ( conf/server.xml), which defaults to 8080. Therefore, the server.port property in application.yml has no effect on the external container.

server:
  port: 8090
  servlet:
    context-path: /demo

Changing the Port for a WAR Deployment

To change the listening port, edit Tomcat’s conf/server.xml and modify the <Connector> element:

<Connector port="8090" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443" />

Why the URL Includes the Project Name

When a WAR is deployed, Tomcat uses the WAR file name as the default context path. For example, a file named order-service.war will be accessible at: http://localhost:8080/order-service/users If you want the application to be reachable at the root context, rename the WAR to ROOT.war or configure a specific context in Tomcat’s Host element.

Jar vs. War Comparison

Web container : JAR – usually embedded Tomcat; WAR – external Tomcat.

Starter : JAR – Spring Boot application starts the container; WAR – external servlet container starts the application.

Launch command : JAR – java -jar; WAR – placed in webapps and loaded by Tomcat.

Port configuration : JAR – server.port in application.yml; WAR – Tomcat’s server.xml.

Default context path : JAR – configurable (default /); WAR – derived from the WAR file name.

Interview Answer Guidance

Instead of saying “JAR is convenient, WAR needs Tomcat”, explain that the key difference is who controls the container. In a JAR, the application bundles and starts its own container, so Spring Boot manages ports and context paths. In a WAR, an external container controls those settings, and the WAR’s name becomes the default context path.

Author’s Preference

The author prefers JAR packaging for most cases because it bundles the application and container together, resulting in a short deployment chain and easier troubleshooting. WAR is chosen only when the organization maintains a shared Tomcat or legacy platforms require WAR files.

Technical Details for WAR Packaging

When building a WAR, the main class should extend SpringBootServletInitializer so that the external servlet container can initialize the Spring Boot application. The Tomcat dependency should be marked as provided to avoid packaging the container twice.

@SpringBootApplication
public class DemoApplication extends SpringBootServletInitializer {
    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        return application.sources(DemoApplication.class);
    }
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

Setting the Tomcat dependency to provided ensures it is used only at runtime by the external container.