Running multiple versions of a servlet web application parallel

Question

I want to run multiple versions (like myapp2.1, myapp2.2 ...) of several Java Servlet based web applications parallel.

One possibility could be to deploy each version to a separate servlet context (which should have its own class loader?!). But I think it will be hard to manage and won't be flexible, since an application is a quite large block. What if an application should contain a service in two different versions? Maybe that is not a good idea ...

The environment will be GlassFish >= 3.0.

What is a better way to run multiple versions of a servlet application parallel? Could OSGI help?

Answer 1

Each web application will be loaded using its own ClassLoader (at least any container I know of; I can't imagine why a container would not do this). So, it should just work. Different versions of your classes will not interfere with one another.

Make sure you do not include any of your classes in the container's own ClassLoader -- for example by putting a .jar in lib/ in Tomcat's directory (not sure of the equivalent for Glassfish). That would be shared by all web applications, and would override whatever is in the web app.

Answer 2

Unless you explicitly configure it to be so, all servlets are multi-threaded and can be invoked several times at once.

So, do you want several web applications with the same code but different names or several servlets inside the same web applciation with different configurations? Please edit your question with a scenario.

---

EDIT: You have now edited the question.

You can simply just name the war file you deploy like application20091230, application20091231, application20100101 and let Glassfish assign it to the corresponding URL. If date is not granular enough, then either a datetime or a buildnumber.

That's what we do for having several versions in a single internal test server.

Answer 3

One possibility could be to deploy each version to a separate servlet context (which should have its own class loader?!).

J2EE applications use separate hierarchy of ClassLoaders and are isolated from each others. Quoting Classloaders and J2EE:

J2EE classloader hierarchy

J2EE specifies that a hierarchy of classloaders is needed to achieve the isolation between applications, but leaves it to the vendors to define the exact structure. However to comply with the J2EE specification, most vendors have classloaders for each of the J2EE application components depending on its location. Further, these classloaders have a hierarchy among themselves, i.e. they have a parent-child relationship. Figure 21.5 shows a sample hierarchy of classloaders. Note that each application server’s classloader hierarchy might slightly differ. Application server vendors sometimes tend to treat two or more of these classloaders as one. For instance, a certain application server might treat Application classloader and EJB classloader to be the same. But the general concepts behind the hierarchy remain the same.

_{Figure 21.5 Sample Classloader Hierarchy in J2EE Application Servers.}

So, yes, each webapp would have its own ClassLoader (thanks god).

But I think it will be hard to manage and won't be flexible.

Why hard to manage? Why not flexible? How many instances are you going to run in parallel? Actually, what problem are you trying to solve? You may get better answer if you describe the real problem. So, can you elaborate a bit?