nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira on 64-bit Windows - switch from EAR/WAR to standalone?

Dave Thomas6

We've been running the EAR/WAR configuration for years, but since the fancy new automated upgrade tools are only available for standalone installations, I've been considering a switch. After further investigation, however, it looks like there's no 64-bit windows standalone installation package.

I guess I *could* let it install 32-bit everything and then swap in the 64-bit procrun and reconfigure Jira to use my 64-bit java. But if I do all that, I'm wondering if the automated upgrades will work after I've finished reconfiguring everything. If I have to go through all the work of reconfiguring, there's not much point in switching from the EAR/WAR configuration unless it buys me something during future upgrades.

Anyone have any experience or advice to lend here? Atlassian support keeps pushing me to consider the standalone setup, but it doesn't seem to make any sense unless you're running linux (where they have a 64-bit standalone installation package available). Am I missing something?

Accepted answers

Dave Thomas6

The silence on this question speaks volumes. After further research and lacking any input to the contrary, I've come to the conclusion that there's no incentive to switch from the EAR/WAR package to the standalone installer package if you're running on a 64-bit version of Windows.

All comments

Dave Thomas6

GilesG

Hi circusdog,

We currently don't provide a 64-bit flavour of the automated Windows Installer for JIRA 4.4+.

This is primarily due to the 'Cause' section mentioned in our 'Problems Installing JIRA as a Service on Windows 64bit' JIRA Knowledge Base article, which in essence is due to Apache Tomcat's lack of 'out-of-the-box' support to run as a native 64-bit Windows Service. Also see JRA-12965 for more discussion on this issue.

However, Thomas B and Michael J, were able to get JIRA up and running on 64-bit Java platforms running on 64-bit versions of Windows, by what appears to be the replacement of specific 32-bit Tomcat executables (in their JIRA installation) with 64-bit versions of these files. For details, check their comments (linked from their names in the previous sentence).

This might work with an installation of the JIRA 4.4.x Standalone distribution.

Hope this helps,

Giles.

Dave Thomas6

Thanks for the links, Giles. We run Jira on 64-bit windows at our company and we do it by replacing the tomcat executables as you've described. If I'm going to do that kind of thing, however, it seems easier to do it with my own copy of tomcat rather than trying to reverse-engineer how the standalone installation has everything wired up and trying to modify it accordingly. I'm also concerned that doing this kind of thing to the standalone instance would break the upgrade process.

I only looked into this because Atlassian support keeps bugging me about the fact that we're installing using the WAR method. They can't understand why we don't use the standalone package. Based on what I've seen, I think we'll keep doing what we're doing until we move everything to linux (probably next year sometime).

Dave Thomas6

I see that Confluence now provides a 64-bit installation package. Hopefully the Jira team will one day follow suit.

GilesG

Hi circusdog,

I don't know if you've checked the JIRA download page recently, but in case not, 64-bit 'recommended distributions' of JIRA are now available.

Incidentally, 'recommended distributions' are what we used to call 'standalone distributions'.

Cheers,

Giles.

pwhack

Hi Giles,

I don't mean to derail this topic but it is similar to what I'm trying to find out. Why is Atlassian's 'recommended distribution' a standalone installer? In other words, why does Atlassian prefer much of its products not be distributed as a WAR/EAR? In my environment most of our in-house applications are WAR files developed and built with Atlassian tools (Bamboo, Crucible, JIRA, Confluence, etc.). I'm in the Operations team and prefer WAR files because we've built tuned VMs specifically for Tomcat6 and Tomcat7 applications. When it comes to deploying new VMs for our Atlassian tools, I keep hearing that we shouldn't use the WAR version.

I'm trying to reconcile that. So what is the vision Atlassian has for its products that can't be accomplished with WARs? My perspective is only from operations and keeping things uniform so I'd like your perspective.

Thanks,

Patrick

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira