CODEWITHSUNDEEP
web-applicationsdeploymentbuild-automationtomcat7
Erel Segal-Halevi
Erel Segal-Halevi

Reputation: 36715

frequent updates of a Tomcat application

I have an application that runs on a Tomcat 7 server on a Windows machine. In its current stage, I have to frequently update and fix it. Whenever I need to update the application, I do all this:

  1. Build a new war file (using ant) on my Linux development computer;
  2. Go to the Windows server, stop the Tomcat service;
  3. download the file from my computer to the Windows computer, put it under webapps;
  4. Remove the old application folder under webapps;
  5. Remove the old application folder under work/Catalina/localhost (otherwise it keeps the old version cached).
  6. Restart the Tomcat service.

I am sure there is a way to do all this automatically. What is it?

Upvotes: 0

Views: 688

Answers (3)

Michał Politowski
Michał Politowski

Reputation: 4385

There are ways to do it.

One way is to use a continuous integration system, for example Jenkins. It would let you build the war regularly or after each commit to a source repository.

Then there is the Jenkins Deploy Plugin that can be used to deploy a war to a running Tomcat instance after it is built. It uses Tomcat's standard manager webapp, so this must be installed in Tomcat, with an user and password set up.

Note that frequent redeployments to a running Tomcat are unfortunately an easy way to find out that your webapp leaks memory on undeployment. OutOfMemory and MemoryLeakProtection articles on the Tomcat wiki are useful reads. Automated Tomcat restarts may be an useful stopgap measure.

Upvotes: 1

mac
mac

Reputation: 5647

With kwatee agile deployment (I'm the developer) you can configure an automated deployment of webapps to tomcat in just a jew minutes (see tutorial). You then trigger the deployment either on-demand via a simple web interface or automatically using the kwatee ant task or the kwatee maven plugin. Oh, it's free too.

Upvotes: 2

Tim Condit
Tim Condit

Reputation: 138

Summary: I'd invest some time in setting up a build and deployment scheme. It's a bit of work up front, but a general solution that can grow as needed after it's set up.

You can accomplish step 1 with an Ant script. You'd first install Ant, and write a short build.xml to include something like this example. With Ant properly installed, you just change to the directory where build.xml is located and run 'ant'.

For steps 2 thru 6, since you need to clean up the target, manage services, etc., I'd look at generating MSI installers or executables. My first choice for an MSI tool is Advanced Installer. You'll see under the list of features that the freeware version allows you to control (start, stop, install, uninstall) Windows services on install and uninstall.

(Side note: we've used Advanced Installer Enterprise for four years. It's continuously improved, and an exceptionally high quality product. You won't be disappointed.)

You can control the MSI creation thru Ant as well. Here's a snip from my build.xml that invokes a couple macros to compile and deploy one of the products I maintain:

<target name="myproduct-installer" depends="unzip-myproductdocs">
    <build-ai-installer product.name="MyProduct" installer.path="setup/installs/MyProduct" project.file="MyProduct.aip" />
</target>
<target name="release-myproduct-installer">
    <release-AI-installer product.name="MyProduct" installer.path="setup/installs/MyProduct" product.path="${some-predefined-target}" />
</target>

Here are the macros used above:

<macrodef name="build-ai-installer">
    <attribute name="product.name" />
    <attribute name="installer.path" />
    <attribute name="project.file" />
    <sequential>
        <echo message="Making installer at @{installer.path}" />
        <mkdir dir="@{installer.path}/newInstall" />
        <exec dir="@{installer.path}" executable="${env.ADVANCEDINSTALLER}" failonerror="true">
            <arg line="/edit @{project.file} /SetVersion ${product.version}" />
        </exec>
        <exec dir="@{installer.path}" executable="${env.ADVANCEDINSTALLER}" failonerror="true">
            <arg line="/build @{project.file}" />
        </exec>
    </sequential>
</macrodef>

<macrodef name="release-AI-installer">
    <attribute name="product.name" />
    <attribute name="installer.path" />
    <attribute name="product.path" />
    <sequential>
        <copy todir="@{product.path}">
            <fileset dir="@{installer.path}/newInstall" />
        </copy>
    </sequential>
</macrodef>

These macros use a Windows environment variable called env.ADVANCEDINSTALLER. Simpler build setups will just set the Ant property and drop the 'env.' prefix:

<property name="ADVANCEDINSTALLER" value="path-to-AdvancedInstaller.com" />

This level of automation pays dividends as soon as it's up and running. But if it's more than you need (I wouldn't be surprised), this answer may help.

Upvotes: 2

Related Questions