How to deploy war to tomcat

Apache Tomcat 8

Tomcat Web Application Deployment

Table of Contents

Introduction

Deployment is the term used for the process of installing a web application (either a 3rd party WAR or your own custom web application) into the Tomcat server.

Web application deployment may be accomplished in a number of ways within the Tomcat server.

The Tomcat Manager is a web application that can be used interactively (via HTML GUI) or programmatically (via URL-based API) to deploy and manage web applications.

There are a number of ways to perform deployment that rely on the Manager web application. Apache Tomcat provides tasks for Apache Ant build tool. Apache Tomcat Maven Plugin project provides integration with Apache Maven. There is also a tool called the Client Deployer, which can be used from a command line and provides additional functionality such as compiling and validating web applications as well as packaging web application into web application resource (WAR) files.

Installation

There is no installation required for static deployment of web applications as this is provided out of the box by Tomcat. Nor is any installation required for deployment functions with the Tomcat Manager, although some configuration is required as detailed in the Tomcat Manager manual. An installation is however required if you wish to use the Tomcat Client Deployer (TCD).

The TCD is not packaged with the Tomcat core distribution, and must therefore be downloaded separately from the Downloads area. The download is usually labelled apache-tomcat-8.0.x-deployer.

TCD has prerequisites of Apache Ant 1.6.2+ and a Java installation. Your environment should define an ANT_HOME environment value pointing to the root of your Ant installation, and a JAVA_HOME value pointing to your Java installation. Additionally, you should ensure Ant’s ant command, and the Java javac compiler command run from the command shell that your operating system provides.

A word on Contexts

In talking about deployment of web applications, the concept of a Context is required to be understood. A Context is what Tomcat calls a web application.

In order to configure a Context within Tomcat a Context Descriptor is required. A Context Descriptor is simply an XML file that contains Tomcat related configuration for a Context, e.g naming resources or session manager configuration. In earlier versions of Tomcat the content of a Context Descriptor configuration was often stored within Tomcat’s primary configuration file server.xml but this is now discouraged (although it currently still works).

Context Descriptors not only help Tomcat to know how to configure Contexts but other tools such as the Tomcat Manager and TCD often use these Context Descriptors to perform their roles properly.

The locations for Context Descriptors are:

Files in (1) are named [webappname].xml but files in (2) are named context.xml. If a Context Descriptor is not provided for a Context, Tomcat configures the Context using default values.

Deployment on Tomcat startup

The web applications present in the location specified by the Host’s (default Host is «localhost») appBase attribute (default appBase is «$CATALINA_BASE/webapps») will be deployed on Tomcat startup only if the Host’s deployOnStartup attribute is «true».

The following deployment sequence will occur on Tomcat startup in that case:

Deploying on a running Tomcat server

It is possible to deploy web applications to a running Tomcat server.

autoDeploy set to «true» and a running Tomcat allows for:

Note that web application reloading can also be configured in the loader, in which case loaded classes will be tracked for changes.

Deploying using the Tomcat Manager

The Tomcat Manager is covered in its own manual page.

Deploying using the Client Deployer Package

It is assumed the user will be familiar with Apache Ant for using the TCD. Apache Ant is a scripted build tool. The TCD comes pre-packaged with a build script to use. Only a modest understanding of Apache Ant is required (installation as listed earlier in this page, and familiarity with using the operating system command shell and configuring environment variables).

The TCD includes Ant tasks, the Jasper page compiler for JSP compilation before deployment, as well as a task which validates the web application Context Descriptor. The validator task (class org.apache.catalina.ant.ValidatorTask ) allows only one parameter: the base path of an exploded web application.

The TCD includes a ready-to-use Ant script, with the following targets:

In order for the deployment to be configured, create a file called deployer.properties in the TCD installation directory root. In this file, add the following name=value pairs per line:

Additionally, you will need to ensure that a user has been setup for the target Tomcat Manager (which TCD uses) otherwise the TCD will not authenticate with the Tomcat Manager and the deployment will fail. To do this, see the Tomcat Manager page.

Comments

Notice: This comments section collects your suggestions on improving documentation for Apache Tomcat.

If you have trouble and need help, read Find Help page and ask your question on the tomcat-users mailing list. Do not ask such questions here. This is not a Q&A section.

The Apache Comments System is explained here. Comments may be removed by our moderators if they are either implemented or considered invalid/off-topic.

How to deploy a WAR file to Tomcat 5 different ways

Community driven content discussing all aspects of software development from DevOps to design patterns.

If you want to develop web applications and Apache Tomcat is your target web server, you need to know how to deploy WAR files to Tomcat so you can see if your applications function at runtime.

Here are five different ways to deploy WAR files to Tomcat.

Perhaps the simplest way to deploy a WAR file to Tomcat is to copy the file to Tomcat’s webapps directory.

Copy and paste WAR files into Tomcat’s webapps directory to deploy them.

Tomcat monitors this webapps directory for changes, and if it finds a new file there, it will attempt to deploy it. If you do your application build on the same machine as your Tomcat server, simply cut and paste it to begin deployment.

If your Java web server is installed on a remote machine, a simple copy and paste won’t work. Instead, you need to perform the network equivalent, a FTP to the remote server. The deployment target remains the same, which is the webapps folder of the remote Apache Tomcat server.

Any popular IDE that supports Java-based development — including Eclipse, NetBeans and IntelliJ — integrates their web development tools with Apache Tomcat, which allows you to deploy with just a mouse click or two.

How to deploy from Eclipse to Tomcat

In Eclipse, all you need to do is right-click on any Servlet, JSP or web project and select:

The Eclipse IDE will build your Java web app, package all of your resources in a web application archive and then deploy the WAR to Tomcat automatically.

If you use Maven as your build tool, you can add deployment features by editing the POM file and specifying the URL and the credentials required to connect and deploy to Tomcat. With the correct POM file configurations made, running the Maven deploy command will result in a complete build, and the packaged web application will be deployed as a WAR file to Tomcat.

Jenkins deployment of a WAR file to Tomcat

Many organizations have embraced the concept of continuous delivery, and a key part of that is the ability to use Jenkins as their continuous deployment tool. There are several Jenkins add-ons available to deploy a WAR file after a CI pipeline successfully runs. One of the most popular ones is the Deploy to Container plugin. Once this plugin is configured, any Jenkins build job can deploy a WAR to Tomcat with the addition of the “Deploy WAR/EAR to a Container” post-build action to the Jenkins job.

The nice thing about Tomcat is its flexibility on how it performs a deployment. There are a variety of different ways to deploy WAR files to Tomcat, be it as simple as a copy and paste, or as involved as the execution of a CI pipeline with Jenkins.

Microsoft’s Azure Advisor service offers recommendations based on five categories. Learn these categories and the roles they play.

Researchers with Palo Alto Networks took the stage at Black Hat to explain how configurations and system privileges in Kubernetes.

How to deploy war to tomcat

The plugin provides various methods of deployment to Tomcat:

These are described in more detail below.

Deploying a WAR file

The simplest way to deploy a WAR project to Tomcat is to type:

This goal will assemble and deploy the WAR file to Tomcat’s manager using HTTP PUT.

Using a different WAR file location

To specify a different WAR file location, add a plugin configuration block to your pom.xml as follows:

Using a context.xml file

If you need to specify a context.xml file when deploying a WAR file to Tomcat, then it must be included within the WAR. The simplest way to achieve this is by adding it to your webapp resources:

Deploying an exploded WAR directory

To avoid building a WAR file upon deployment, a WAR directory can instead be deployed to Tomcat by typing:

Using a different WAR directory location

To specify a different WAR directory location, add a plugin configuration block to your pom.xml as follows:

Using a context.xml file

To supply a context.xml when deploying a WAR directory, add a plugin configuration block to your pom.xml as follows:

The default context.xml file use is located at src/main/webapp/META-INF/context.xml.

Using a different context.xml file location

To specify a different context.xml file location, add a plugin configuration block to your pom.xml as follows:

Deploying an in-place WAR directory

To avoid copying resources to the build directory, the webapp source directory can be deployed to Tomcat by typing:

Using a different WAR directory location

To specify a different WAR directory location, add a plugin configuration block to your pom.xml as follows:

The default location is $/src/main/webapp.

Using a context.xml file

To supply a context.xml when deploying a WAR directory to Tomcat, add a plugin configuration block to your pom.xml as follows:

The default context.xml file used is located at src/main/webapp/META-INF/context.xml.

Using a different context.xml file location

To specify a different context.xml file location, add a plugin configuration block to your pom.xml as follows:

Deploying a context.xml file

To simply deploy just a context.xml file to Tomcat:

The default context.xml file used is located at src/main/webapp/META-INF/context.xml.

Using a different context.xml file location

To specify a different context.xml file location, add a plugin configuration block to your pom.xml as follows:

Running a WAR project

A WAR project can be run under an embedded Tomcat server by typing:

To stop the embedded server, press CTRL+C.

Copyright © 2005–2014 The Apache Software Foundation. All rights reserved.

Apache Tomcat 9

Tomcat Web Application Manager How To

Table of Contents

Introduction

In many production environments it is very useful to have the capability to manage your web applications without having to shut down and restart Tomcat. This document is for the HTML web interface to the web application manager.

The interface is divided into six sections:

Message

Displays information about the success or failure of the last web application manager command you performed. If it succeeded OK is displayed and may be followed by a success message. If it failed FAIL is displayed followed by an error message. Common failure messages are documented below for each command. The complete list of failure messages for each command can be found in the manager web application documentation.

Manager

The Manager section has three links:

Applications

The Applications section lists information about all the installed web applications and provides links for managing them. For each web application the following is displayed:

Start

Signal a stopped application to restart, and make itself available again. Stopping and starting is useful, for example, if the database required by your application becomes temporarily unavailable. It is usually better to stop the web application that relies on this database rather than letting users continuously encounter database exceptions.

If this command succeeds, you will see a Message like this:

Otherwise, the Message will start with FAIL and include an error message. Possible causes for problems include:

An exception was encountered trying to start the web application. Check the Tomcat logs for the details.

There is no deployed application on the context path that you specified.

The path parameter is required.

Signal an existing application to make itself unavailable, but leave it deployed. Any request that comes in while an application is stopped will see an HTTP error 404, and this application will show as «stopped» on a list applications command.

If this command succeeds, you will see a Message like this:

Otherwise, the Message will start with FAIL and include an error message. Possible causes for problems include:

An exception was encountered trying to stop the web application. Check the Tomcat logs for the details.

There is no deployed application on the context path that you specified.

The path parameter is required.

Reload

Signal an existing application to shut itself down and reload. This can be useful when the web application context is not reloadable and you have updated classes or property files in the /WEB-INF/classes directory or when you have added or updated jar files in the /WEB-INF/lib directory.

NOTE: The /WEB-INF/web.xml web application configuration file is not checked on a reload; the previous web.xml configuration is used. If you have made changes to your web.xml file you must stop then start the web application.

If this command succeeds, you will see a Message like this:

Otherwise, the Message will start with FAIL and include an error message. Possible causes for problems include:

An exception was encountered trying to restart the web application. Check the Tomcat logs for the details.

There is no deployed application on the context path that you specified.

The path parameter is required.

Currently, application reloading (to pick up changes to the classes or web.xml file) is not supported when a web application is installed directly from a WAR file, which happens when the host is configured to not unpack WAR files. As it only works when the web application is installed from an unpacked directory, if you are using a WAR file, you should undeploy and then deploy the application again to pick up your changes.

Undeploy

Signal an existing application to gracefully shut itself down, and then remove it from Tomcat (which also makes this context path available for reuse later). This command is the logical opposite of the /deploy Ant command, and the related deploy features available in the HTML manager.

If this command succeeds, you will see a Message like this:

Otherwise, the Message will start with FAIL and include an error message. Possible causes for problems include:

An exception was encountered trying to undeploy the web application. Check the Tomcat logs for the details.

There is no deployed application on the context path that you specified.

Deploy

Web applications can be deployed using files or directories located on the Tomcat server or you can upload a web application archive (WAR) file to the server.

To install an application, fill in the appropriate fields for the type of install you want to do and then submit it using the Install button.

Deploy directory or WAR file located on server

Deploy and start a new web application, attached to the specified Context Path: (which must not be in use by any other web application). This command is the logical opposite of the Undeploy command.

There are a number of different ways the deploy command can be used.

Deploy a Directory or WAR by URL

Install a web application directory or «.war» file located on the Tomcat server. If no Context Path is specified, the directory name or the war file name without the «.war» extension is used as the path. The WAR or Directory URL specifies a URL (including the file: scheme) for either a directory or a web application archive (WAR) file. The supported syntax for a URL referring to a WAR file is described on the Javadocs page for the java.net.JarURLConnection class. Use only URLs that refer to the entire WAR file.

Deploy a Directory or War from the Host appBase

Install a web application directory or «.war» file located in your Host appBase directory. If no Context Path is specified the directory name or the war file name without the «.war» extension is used as the path.

Deploy using a Context configuration «.xml» file

If the Host deployXML flag is set to true, you can install a web application using a Context configuration «.xml» file and an optional «.war» file or web application directory. The Context Path is not used when installing a web application using a context «.xml» configuration file.

A Context configuration «.xml» file can contain valid XML for a web application Context just as if it were configured in your Tomcat server.xml configuration file. Here is an example for Tomcat running on Windows:

Use of the WAR or Directory URL is optional. When used to select a web application «.war» file or directory it overrides any docBase configured in the context configuration «.xml» file.

Here is an example of installing an application using a Context configuration «.xml» file for Tomcat running on Windows.

Here is an example of installing an application using a Context configuration «.xml» file and a web application «.war» file located on the server (Tomcat running on Unix).

Upload a WAR file to install

Upload a WAR file from your local system and install it into the appBase for your Host. The name of the WAR file without the «.war» extension is used as the context path name.

Use the Browse button to select a WAR file to upload to the server from your local desktop system.

Upload of a WAR file could fail for the following reasons:

The upload install will only accept files which have the filename extension of «.war».

If a war file of the same name already exists in your Host’s appBase the upload will fail. Either undeploy the existing war file from your Host’s appBase or upload the new war file using a different name.

The file upload failed, no file was received by the server.

The war file upload or install failed with a Java Exception. The exception message will be listed.

Deployment Notes

If the Host is configured with unpackWARs=true and you install a war file, the war will be unpacked into a directory in your Host appBase directory.

If the application war or directory is deployed in your Host appBase directory and either the Host is configured with autoDeploy=true the Context path must match the directory name or war file name without the «.war» extension.

For security when untrusted users can manage web applications, the Host deployXML flag can be set to false. This prevents untrusted users from installing web applications using a configuration XML file and also prevents them from installing application directories or «.war» files located outside of their Host appBase.

Deploy Message

If deployment and startup is successful, you will receive a Message like this:

Otherwise, the Message will start with FAIL and include an error message. Possible causes for problems include:

The context paths for all currently running web applications must be unique. Therefore, you must either undeploy the existing web application using this context path, or choose a different context path for the new one.

The URL specified by the WAR or Directory URL: field must identify a directory on this server that contains the «unpacked» version of a web application, or the absolute URL of a web application archive (WAR) file that contains this application. Correct the value entered for the WAR or Directory URL: field.

An exception was encountered trying to start the new web application. Check the Tomcat logs for the details, but likely explanations include problems parsing your /WEB-INF/web.xml file, or missing classes encountered when initializing application event listeners and filters.

If the application war or directory is deployed in your Host appBase directory and either the Host is configured with autoDeploy=true the Context path must match the directory name or war file name without the «.war» extension.

If the Host deployXML flag is set to false this error will happen if an attempt is made to install a web application directory or «.war» file outside of the Host appBase directory.

Diagnostics

Finding memory leaks

The find leaks diagnostic triggers a full garbage collection. It should be used with extreme caution on production systems.

The find leaks diagnostic attempts to identify web applications that have caused memory leaks when they were stopped, reloaded or undeployed. Results should always be confirmed with a profiler. The diagnostic uses additional functionality provided by the StandardHost implementation. It will not work if a custom host is used that does not extend StandardHost.

This diagnostic will list context paths for the web applications that were stopped, reloaded or undeployed, but which classes from the previous runs are still present in memory, thus being a memory leak. If an application has been reloaded several times, it may be listed several times.

Server Information

This section displays information about Tomcat, the operating system of the server Tomcat is hosted on, the Java Virtual Machine Tomcat is running in, the primary host name of the server (may not be the host name used to access Tomcat) and the primary IP address of the server (may not be the IP address used to access Tomcat).

How to deploy a war file in Tomcat 7

Now how will Tomcat deploy it, I mean do I need to open it in browser? How can I access the application?

13 Answers 13

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

You can access your application from: http://localhost:8080/sample

If it doesn’t open properly, check the log files (e.g. tomcat/logs/catalina.out) for problems with deployment.

step-1. here I’m deploying pos.war First go to tomcat webapps folder and paste it

step-2. go to tomcat->bin folder start tomcat by clicking startup.bat

step-3. go to browser write localhost:port/project name eg. localhost:8080/pos (here my tomcat run on port 8080)

You just need to put your war file in webapps and then start your server.

it will get deployed.

otherwise you can also use tomcat manager a webfront to upload & deploy your war remotely.

Access the following URL:

The available main paths are here: [

/manager/html (E.g.: http://localhost:8080/manager/html ) and they have true on the «Running» column.

Using the UI manager:

/manager/html/ (usually localhost:8080/manager/html/ )

This is also achievable from [

> Manager App)

go to %CATALINA_HOME%\conf\tomcat-users.xml and check that you have enabled a line like this:

Here’s a longer how-to and other instructions from the Tomcat 7 documentation pages.

There are two ways:

Just use tomcat manager console for console deployment or simply copy and paste your application in webapp folder of your server’s tomcat_home directory.

Note: Make sure if your war file size is more than 52 MB (the default configuration value), you need to make two little changes in web.xml file of Manager application of your webapp folder(Manager application is provided by Apache tomcat by default upon installing the server).

Go to the web.xml of the manager application (for instance it could be under /tomcat7/webapps/manager/WEB-INF/web.xml.

Increase the max-file-size and max-request-size values in web.xml file:

Increase the size by putting the values for and according to your requirement.