Skip to content Skip to sidebar Skip to footer
Home / Css / Deployment / Java / Javascript

Different WAR Files, Shared Resources

Post a Comment
Suppose you have several applications which share the same code and most of the other resources, but have a somewhat different look and feel, some labels change, etc. (think brand

Solution 1:

You can deploy both WARs in the same EAR and put common resources in the EAR. Then put the appropriate dependencies in the manifest of the web apps to link to the jar files in the ear.


Solution 2:

A strategy that I have seen used for such product-line like configurations is using WAR overlays when building with maven. You define a common WAR that contains the common stuff and overlay it with those other WARs that contain the specific stuff to generate different WARs for every application. This method is probably most useful if you deploy the WAR-variants on different machines. But I'm not sure whether I can actually recommend this.

Remember to specify the overlays configuration if you actually override stuff, since otherwise the overriding order is not deterministic. It might even change with a maven-war-plugin upgrade. (It did in our case.)


Solution 3:

If you don't want to go the EAR route, using tomcat, etc; there are a few other ways to achieve the consistency you want.

If you want to share just js and css, look into pack:tag. You could host the .js and css from an apache server, set up your httpd.conf so your webapps can call it, then use pack:tag from your application wars - DRY and compression in one step.


Solution 4:

Thanks for the replies so far, but I'm afraid I forgot to mention that the WARs will be deployed in different environments that are completely isolated from each other.

So maybe having a common WAR deployed next to the actual application is the only option. I think I'll go with the following:

  • WAR1, WAR2 containing app-specific stuff
  • CommonWAR containg common stuff (no kidding)
  • EAR1: WAR1 + CommonWAR, to be deployed in env1
  • EAR2: WAR2 + CommonWAR, to be deployed in env2

Solution 5:

Update

Yes, me again. I have actually changed my mind (again :) ). I am currently trying (being more prudent here):

  • (Common)WAR: containing the application, common (most part) + some specific stuff
  • EAR1: CommonWAR + specific configuration file for env1
  • EAR2: CommonWAR + specific configuration file for env2

The configuration file is picked up by the WAR. It is on the the EAR classpath and only contains one property 'application' with a value. The single WAR will then use this information where appropriate to distinguish between the two apps (config, style sheets, ...).

With my solution of EAR1 = CommonWAR + WAR1, EAR2 = CommonWAR + WAR2, it was too difficult or impossible to lookup static resources in the CommonWAR without using a web url (e.g. images in PDF documents generated with iText).


Post a Comment for "Different WAR Files, Shared Resources"