Efficiently deploy multiple instances of same WAR ( different contexts, same container )
glassfish, java, jetty, tomcat, war
Solution
Jetty added support for what you looking for a while back with what are called overlays.
http://wiki.eclipse.org/Jetty/Tutorial/Configuring_the_Jetty_Overlay_Deployer
Copying a bit from the wiki page:
- You can keep the WAR file immutable, even signed, so that it is clear which version you have deployed.
- All modifications you make to customise/configure the web application are separate WARs, and thus are easily identifiable for review and migration to new versions.
- You can create a parameterised template overlay that contains common customisations and configuration that apply to many instances of the web application (for example, for multi-tenant deployment).
- Because the layered deployment clearly identifies the common and instance specific components, Jetty is able to share classloaders and static resource caches for the template, greatly reducing the memory footprint of multiple instances.
Problem
I have one WAR ( app.war ) and one container ( Tomcat, Jetty, Glassfish, whatever ). My goal is to deploy, on demand, hundreds of instances of this same web application on the container. ``` http://foo/app1 --> app.war http://foo/app2 --> app.war http://foo/app3 --> app.war ... http://foo/appN --> app.war ``` Some obvious ways of achieving this: - In Tomcat, create one context.xml file for each app ( named appN.xml ), all pointing to the same WAR. Other containers have similar methods - Problem with this approach: It will explode the WAR N times, taking up a lot of disk space - Use symbolic links to create webapp/{app1,app2,appN} folders pointing to an exploded version of app.war. This prevents the disk space explosion, but the JVM is still loading many duplicate JARs to memory - Use some shared lib folder to contain most jars ( and a combination of the previous two options ). I wonder if there is a better method to do this. Ideally, creating a new instance should not take up ANY more disk space ( other than marginal configuration files ) and only take up memory related to thread execution stacks and other runtime allocations. Any ideas?