I have this question for few months now.

We have a web application which has monthly changes and weekly bug fixes if any.

Usually we just build the new war, undeploy the old ones and redeploy new ones, and restart server if necessary.

I want to build a patching system which can create a patch which can easily be applied for the current war itself.

I googled a lot but didn't find any.

My doubts are:

  1. Is it okay to create such an application ? (Specifically for this WAR application)
  2. Which language to use ? (I was thinking of Go or JAVA but open to suggestions.

Please point me any documentations of blogs. Thanks in advance :)

  • What benefits do you hope to gain from such a system? What exactly in your process makes it hard to generate a war file?
    – reto
    Commented Apr 8, 2015 at 8:11
  • If you redeploy your app manually each time, maybe you should consider using configuration management tools. Updating WAR seems like a bad idea since WAR files are meant to be the units of deployment.
    – scriptin
    Commented Apr 8, 2015 at 11:59
  • @reto No, its not hard to build a new war file, but we have 4 servers where user has to do it manually. That was my main concern. Commented Apr 8, 2015 at 12:49

2 Answers 2


Yes, it is quite possible, and I have done such myself.

The situation I was in was deployment of a large .war file. The web application part of it was not that big - but it also contained within it a Java Web Start application. The combined size of all of this was a few hundred megabytes. This posed a problem for deployment - when pushing all of this down the pipe to all the sites that needed it (about 300), we could thoroughly saturate the network all night which meant that other updates were not happening (that was a bad thing).

The solution to this was two part. First, we did an exploded deployment of all code we used (third party .jars were still a .jar). Secondly, as part of our CI server we had a special build script that could take two builds identify the delta of the class files and other resources (whole file delta, not sub file patches) and then with that, it would build the deployment package (a .tar file and shell script that stopped the server, deployed itself, and restarted the server - the JWS then did its own deployment when the clients started up) that would patch a production environment from one build to another.

A thing to take away from all this is that there were several constraints here - a very large application and network utilization. This made an incremental deployment necessary.

For a situation where you have a few servers, I would be looking at another approach.

First off, version the .war file. You don't deploy "FooApp", you deploy "FooApp_1_0_1". This also means you have both "FooApp_1_0_0" and "FooApp_1_0_1" on the server at the same time.

Secondly, you have the forward proxy or load balancer have its configuration point "FooApp" to "FooApp_1_0_0" and then switch that configuration when you want to flip the switch. This would typically be done after you have verified that the new deployment is completely working.

The deployment can be done via your CI server (and if you don't have one running, that would be a good thing to work on). Jenkins has deployment plugins for all the major EE servers. Maven also has deployment plugins - I am sure gradle and ant do too. You could also write your own using JMX for some app servers. If you really wanted, you could probably write another app that runs on the app server to deploy the other app. I would be hesitant to have an app update itself in running code. That just sounds like a nightmare if something breaks part way through.

The biggest advantages with versioned deployment and a load balancer / forward proxy switch over is that you can do this deployment with zero down time and verify the deployment before it goes live. At no time are you updating running code or even restarting the application server as part of this. The switch for which code to run is another system entirely. This situation also allows for instant rollbacks and special client switching ("you have been selected to try our new look and feel, click this to go to the new version of the application and provide feedback").

  • I will surely try this out. I specifically liked the idea of versioning. At this point as we have multiple servers, we just do it one by one, so at any point of time, the site is never down. Thanks :) Commented Apr 8, 2015 at 17:56

Yes. It is possible to patch a JAR file using jar -u. It is also possible to patch a WAR file the same way.

But I would NOT recommend it. The JAR or WAR file should be the unit of deployment / management. If you start patching JAR / WAR files on production servers, it is hard to track what is actually being used where. If you are not careful, chaos and confusion will reign.

The only situation where patching is unavoidable is where you have a 3rd-party library or something that you can't build from source, but you need to modify nevertheless. But even in that case it is best to modify the JAR / WAR on your build platform and deploy the modified JAR / WAR. Trying to patch JARs, WARs or deployed webapps on the production platform is a bad idea.

  • You can update the old jar by doing jar uf jarfile classfile(s)
    – Vijay Goel
    Commented Apr 8, 2015 at 11:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.