13

I'm using tomcat to deploy my applications, I would like to deploy as one single war to should server multiple context paths.

Currently I have app1.war and app2.war, but both has same contents only name is different to access via http:///app1 and http:///app1.war. But I would like to do this, Deploy app.war and access it by both app1 and app2 context path. Is it possible to do in tomcat? Please help me out of this

Selvakumar Ponnusamy
  • 4,414
  • 7
  • 33
  • 65
  • 1
    Should it still be the same webapp (sharing same local data) or should the webapps really be seperate instances? – Daniel Jun 10 '14 at 10:17

1 Answers1

21

This can be done in several ways. I think this way is the most straightforward:

  1. Move the WAR file outside of the webapps/ auto-deploy directory
  2. Extract META-INF/context.xml from your WAR file. If your WAR doesn't have a META-INF/context.xml file, just use a file with nothing but <Context /> in it
  3. Copy this file into Tomcat's conf/[service]/[host]/ directory as both app1.xml and app2.xml. (The [service] is usually "Catalina" and the [host] is whatever the name of your virtual host is: on a default Tomcat configuration, the hostname is always "localhost").
  4. Edit both app1.xml and app2.xml and set the docBase attribute for the <Context> element to point to the WAR file you moved in step #1
  5. Re-start Tomcat

This ought to give you a single physical WAR file and multiple contexts deployed from it.

Although Tomcat supports this configuration, I recommend against it: disk space is cheap, it changes nothing at runtime (you still get two copies of everything in memory), and you lose the flexibility of deploying different WAR files to different contexts and/or updating them separately without modifying the configuration of both contexts.

If you want my advice, stick to duplicate WAR files.

Christopher Schultz
  • 18,184
  • 5
  • 54
  • 70
  • 1
    I think I agree with sticking to duplicate WARs, but I'm in a similar situation and find that having a single artifact to push through a continuous delivery pipeline is very neat. It's also worth mentioning that if you put WARs outside the host appBase, they can't be unpacked (as of Tomcat v7), so if you have an app (like I do, sadly) that requires unpacking, the above is not an option. – Conan Mar 27 '14 at 17:31
  • 1
    Such WARs *can* be unpacked, but you'll have to unpack them yourself. It is possible to script all of this, of course. – Christopher Schultz Mar 28 '14 at 20:31
  • @peterh You must have misunderstood either the question, or the answer, or both, then. Sharing a WAR file between distinct contexts still gets you two completely-separate `ClassLoader`s and a whole (literally) heap of data which is separate for each context's deployment. You don't save a single byte of JVM memory by sharing a WAR file between contexts. Hence, my comment about "disk space [being] cheap." – Christopher Schultz May 29 '18 at 20:12
  • @peterh I dunno... memory is pretty cheap, too. Your application's memory *should* be dominated by working objects that your application is creating, not by representations of `Class` objects in memory in a `ClassLoader`. So doubling the heap-size by deploying a second context shouldn't make much of a difference. – Christopher Schultz May 30 '18 at 13:41
  • @ChristopherSchultz Does having a single docBase WAR speed up the time tomcat takes to start? I currently have about 20 duplicate war files and each takes about 3-4 seconds to deploy serially during startup, so tomcat is taking a long time. Will multiple XML contexts all pointing to the one WAR help? – Edward Feb 15 '21 at 09:09
  • 1
    @Edward You might want to ask this in a separate question, but, briefly: no, using a single WAR file (or WAR-structured directory) will not improve startup time. You will get a separate ClassLoader for each context and your application will launch N separate times regardless. You might want to look into "parallel deployment" in Tomcat which can launch your applications simultaneously instead of serially, especially if you have spare capacity available at startup. – Christopher Schultz Feb 16 '21 at 18:53