Question

I am having war file deployment at customer site. War file contains lib folder which contains dependent jars e.g.

/lib/app-01.jar
/lib/spring-2.5.1.jar
/lib/somefile-1.2.jar
…
…

If we need to update lets say app-01.jar to app-02.jar, is there any elegant solution? how does these dependent jars are packaged into WAR file as industry standard?

Is it good idea to package those dependent jars without version number?
e.g.

/lib/app.jar
/lib/spring.jar
/lib/somefile.jar
…
…

EDIT NOTE:
Actually, War is deployed to Webshpere, WebLogic, Tomcat on Windows or Linux platform. And Customer’s IT department is involved for deployment

Answer 1

Probably the most elegant solution is just to generate a new war, and deploy it.

Here are the reasons:

• If you are worried about uptime, some application servers supports side by side deployment. It means that you can deploy a new version and have it up at the same time of the old one. And stop the old when no one is using it. (I’ve used that on WebLogic, like 5yrs ago, so I suppose that is a common feature now). But that kind of feature only works if you deploy a new .WAR version.

• Probably the WAR was generated using Maven, Ant or Gradle, so changing the dependency version and do a mvn package is usually faster and less error prone than unzipping the WAR, change it, and zip it again.

• All the application servers provides a “hot replace” feature, that works by refreshing the class loader. Its fine for development, but in production it can be problematic (class loader leaks can be common, and problems caused by incorrect initialization or bad programming practices can give you unexpected bugs like having two versions of a class)

About JAR file names: I recommend to keep the versions on the file name.
Most of the JARs contains version information inside META-INF/Manifest.mf. But if for some reason you have to know which versions are using your app… opening each JAR file to see the version in the manifest is a lot of work.

As a final advice. If you don’t use any automatic build tool… adopt one (take a look to Gradle, which is nice). Updating a library version, usually consist on changing the version number on the build file and execute something like gradle deploy. Even if you are not the developer, but the one in charge of devops, having an automated build is going to help you with deployments and updates.