views:

245

answers:

3

Currently, we support many clients using the same web app, but each client has a different configuration for accessing their database, setting files etc. As the client list grows, updating the web apps is becoming increasingly arduous, and the duplication of resources is a waste of memory, file space, etc..

What we'd like to do is have a parent web app which is shared by all children web apps. Then have each child web app carry only files specific to them. When the child web app starts up, Tomcat loads the web app from the parent web app and then overrides any files defined in the child web app following an identical package structure.

We've been googling around and haven't found a ready or complete solution. Solutions we've looked at:

  1. Tomcat common/share - could handle class and JAR files, but we don't see a way to handle static and JSP resources residing above the WEB-INF dir.
  2. CATALINA_BASE appears to be more suited for running multiple instances of Tomcat which we'd rather avoid
  3. A Maven possible solution, but we are not big fans of Maven, so would rather avoid it also.

Anybody have suggestions or ideas on how to solve this? If Tomcat configuration is not possible, what about a different application server (such as Glassfish) or a tool for doing dynamic file updated (such as OSGi, rsync). Would like to remove the resource duplication if possible.

Thank you.

+1  A: 

There is no such thing as "parent" or "child" webapps. It's not part of J2EE spec and AFAIK it's not supported by any application server.

That said, your problem is twofold:

1) Having shared resources. This part is pretty easy assuming "resources" means static resources (images / CSS / javascript / etc...).

  • If they are truly shared (e.g. you don't need to have a separate version in some of your webapps), host them elsewhere (separate "common" webapp or put Apache in front of your Tomcat and host them there.
  • If you do need to have "local" versions of some of those resources you may be able to do some clever conditional URL rewriting or simply write a servlet that would check whether particular resource exists locally and, if not, take it from "common" location.
  • Precompile your JSPs so you only have to deal with JARs.
  • If your Tomcat instance only hosts your apps, you can indeed put your JARs in shared (or lib in the latest version); otherwise you can deploy them with each application .

2) Simplifying deployment. I'm not really sure what the big problem is here... It's rather trivial to write an Ant (batch, shell, what have you) script that would assemble and deploy WARs based on "common" and "per-app" directory structures.

Alternatively, you may want to take a look at using JNDI to severely reduce the number of files that have to be deployed (in theory, to a single context.xml for each application).

ChssPly76
A: 

You can build parent-child hierarchy if you use Spring at your web-apps - Using a shared parent application context in a multi-war Spring application.

I.e. you can define all shared stuff at the 'parent' context and have 'child' contexts just to use it.

denis.zhdanov
Having a shared Spring context has nothing to do with having shared resources. To be honest, I can't even think of where if would be useful in this scenario (that is, if OP uses Spring at all)
ChssPly76
A: 

If all you had was setting file and configuration changes you could manage these through the context.xml and then you can point the docBase of each application context at a common directory for all the applications to share the same source.

the drawback to this is changes to the application will require a tomcat restart.

This does not however solve your problem if you want to override logic.

A option that I am exploring for a similar scenario is to move the client custom portion into ajax widgets / gadgets. Then have it be part of the configuration files to tell the application which version of the gadget to pull for which client.

you can review documentation for having applications share a docbase here http://tomcat.apache.org/tomcat-5.5-doc/config/context.html

smokeysonora