How to update the tomcat in an JIRA standalone installation

Our central IT department requested me to update our tomcat which came along with the JIRA installation. There had been some security issues with tomcat, which are now fixed with the new version 6.0.36 of tomcat. How do I apply a newer version of tomcat to my current JIRA standalone installation?

An update to a newer version of JIRA is a no-go, because this would mean some months of testing of self written plugins, classes and other configuration changes we made. In the questions/answers section of Atlassians web site I did not find any hint about tomcat updates. Only information regarding Java update I found.

4 answers

1 vote
Ahmad Danial Atlassian Team Nov 07, 2012

Hey there, Johannes.

The option of installing JIRA using the WAR distribution is the alternative approach to this.


As Nic had mentioned, it is a yes / no situation. Since you will need to ensure that every detail is taken care of, it might be a bit of a hassle to move to WAR. Upgrading is the best option to this but since you mentioned that it is not possible, WAR is the only option to this.

Warm regards,


0 votes

Ugh, this is one of the main reasons I avoid using standalone. It's a bit of a pig to upgrade the Tomcat underneath it.

In theory, you should be able to take a standard tomcat of the current version, unpack it, work your way through all the files that it contains so that you know what is in there. Then compare it to all the files in the standalone version to find out what Atlassian has modified. Then you get the new Tomcat installation and install it over the top, merging in any changes Atlassian has done (they aren't huge)

For a far more simple life, you could either tell your IT department "no", or you could move to the WAR distribution and use it in any Tomcat you like.

I discussed this with my boss. As this seems to be the way of the least effort, we will try to 'merge' a new tomcat distribution into JIRA. If it is of interest to anyone, I can give a report about the procedure afterwards. Moving to (and afterwards maintaining) EAR/WAR needs too much of ressources (that was the reason for picking the standalone version).

I really don't think you've thought this through properly. Have you compared every single file yet? Worked out exactly what you need to change? Checked for the upgrades and changes in every supporting library?

The EAR/WAR version, built off-the-shelf is more difficult to implement and maintain. But it's a lot easier than trying to pull the WAR stuff out of a standalone and push it into another Tomcat.

I thought the other way round: Take the new version of tomcat and replace the corresponding files in the JIRA installation. It worked with 32 to 64 bit migration (only 3 files to replace) and at the moment the effort seems not to be higher than for the alternatives.

What about the supporting libraries? It's ok moving the web-app itself, but the Tomcat installation is now missing quite a lot of stuff, and a quick "diff" found around 30 files in the Tomcat install that would need checking for merge...

Hi Ahmad,

thanks for the new feature request. As commented above, we will try to integrate the new tomcat version. All other options cost too much of effort.

Best regards


It would be pretty easy, because JIRA standalone is just a pre-configured Tomcat plus the jira war app.


Java Web apps (.war) are deployed in the Tomcat webapps directory, so you can access them via url.

Example: if myapp.war into the $TOMCAT_HOME/webapps directory, it'll deployed at:


so you can access

http://tomcat_host:tomcat_port/myapp (<-Notice that the app context is myapp. Even this can be configured)

There is a "special" Tomcat directory:ROOT located at


Why ROOT name? beause files put there are accessed from the root url. Example:

$TOMCAT_HOME/webapps/ROOT/my_file.html is accessed from

http://tomcat_host:tomcat_port/my_file.html (<- Notice that app context is empty -> ROOT)


1) JIRA Standalone is deployed on the ROOT directory.

2) The ROOT directoy has been moved up.

That's all.

The location of the ROOT directory can be configured, and Atlassian did it.

There is nothing extrange in JIRA Standalone. Only a Tomcat with few configuration stuff done by Atlassian, so the Tomcat instance can be easily replaced (overwriten) whether you have a bit/enough knowledge.

Briefly, as the Tomcat configuration is done in the /conf file, then you have to preserve them. Usually Tomcat keeps compatibility across versions, but you have to be very careful with that.

As Danial suggested, the right way would be deploy the war file on a clean Tomcat instance.


And the missing libraries? If you're deploying WAR on a clean Tomcat, you need to add libraries. If you've got an existing Tomcat and you overwrite it with a new one, you need to check them for updates. And merge the config files.

If you're going to overwrite the Tomcat and go to all the effort of merging, you might as well just get a clean Tomcat, and er, deploy the WAR distribution...

Yes, overwritting Tomcat is not the right way for sure. However, the intesting thing is understanding how Tomcat is configured to run as JIRA Santandalone, I think.

Yes, I never got very far into it - my comments here are based on trying to do much the same. If you know exactly what Atlassian have tweaked to get standalone in it's current shape, it wouldn't be too hard, but I don't. Grabbing a WAR is far more simple than the investigations to work that out!

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted yesterday in United States

From Atlassian: Confluence Security Advisory - 2019-03-20

Atlassian released a security advisory on 3/20/2019.  The full advisory is here: In a nutshe...

22 views 0 1
View post

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you