Deploy to web container, bundle web container or embed web container

Question

I am developing an application that needs to be as simple as possible to install for the end user. While the end users will likely be experience Linux users (or sales engineers), they don't really know anything about Tomcat, Jetty, etc, nor do I think they should.

So I see 3 ways to deploy our applications. I should also state that this is the first app that I have had to deploy that had a web interface, so I haven't really faced this question before.

First is to deploy the application into an existing web container. Since we only deploy to Suse or RedHat this seems easy enough to do. However, we're not big on the idea of multiple apps running in one web container. It makes it harder to take down just one app.

The next option is to just bundle Tomcat or Jetty and have the startup/shutdown scripts launch our bundled web container.

Or 3rd, embed.. This will probably provide the same user experience as the second option.

I'm curious what others do when faced with this problem to make it as fool proof as possible on the end user.

I've almost ruled out deploying into an existing web container as we often like to set per application resource limits and CPU affinity, which I believe would affect all apps deployed into a web container/app server and not just a specific application.

Thank you.

Answer 1

Deploying multiple war files (or ear files in case of full Java EE application server) was an idea that was once a promise, but in practice didn't play out very well.

A major problem is that despite major advances, hot reloading of WARs of EARs remains problematic. Memory leaks, resource leaks, class loader problems... they keep happening. The safest way to redeploy is thus to restart the whole servlet container or application server, but this takes down all other apps running on it with it.

A second problem with deploying multiple apps to a single AS is that their is only a thin layer of isolation between them. Applications can access resources in JNDI from other applications. This might not be a problem for cooperating applications, but it's really a problem for apps that are possibly hostile to each other.

In general, a servlet container is thus not a replacement for a multi-tasking, isolating operating system.

With the availability of inexpensive and efficient virtualizing products like Xen it seems to be a better option to just have one application per servlet container (indeed, bundle them) and deploy these to a Xen client.

An additional advantage of this is that it provides an easier path to upgrade the libraries on which your application depends. If you consider a fixed installation of Tomcat 6 as the deployment platform, then a single application can not just upgrade to Servlet 3.0 from Tomcat 7, since this will effect all other applications running on that same Tomcat. This is even more important for full Java EE stacks like JBoss AS, since these bundle way more libraries.

In practice this often means that with a fixed Tomcat that runs multiple apps, you can simply never upgrade your app to take advantage of newer libraries/apis offered by Tomcat, since there's always some other app that for some reason or the other can't be upgraded. This very quickly degrades into a total nightmare.