Third party libraries best practice in Tomcat

Question

I am using Tomcat for hosting my Java Web and Web Service applications for a long time now. Mostly for Spring and Grails applications at the moment.

Lately in one project a discussion came up, about how deal with dependencies/libraries in Tomcat production environments:

In my projects I am deploying big WAR files holding all the required dependencies for the application in WEB-INF/lib folder. The only things I put in the tomcat/lib folder are the JAR files for JDBC connections managed by tomcat.

The customer has a long history with WebSphere and thinks the container should hold most of the the required dependencies. So they want to put JAR files for used frameworks or WebService API's (like Metro) in the tomcat/lib folder and have skinny WAR files.

The problem with that solution in my opinion is that if you have an application that requires another version of a dependency that is already included in the tomcat/lib folder you can get errors and strange behavior.

Is there some best practice or official document that talks about this issue? What is your opinion about this?

Answer 1

Packaging dependent jars into the war file may yield a bigger war file, but it provides a lot of benefits. The big war file becomes a single, self-contained, complete unit of deployment. You can take that war file and deploy it to a developer desktop, a customer acceptance environment, and a production environment, and have confidence that your own code in the war file is referencing the expected versions of all dependencies.

In my experience, the only time to place a jar into Tomcat's lib folder instead of the war file is when your code references some library by interface, and you won't know the underlying implementation until deployment time. For example, I had a project integrating with JMS, and I knew that I had to support multiple deployments of the messaging infrastructure. Some environments needed to use ActiveMQ. Other environments needed to use Websphere MQ. In that case, I packaged the JMS interface jar into the war file, and then at deployment time, I placed either the ActiveMQ or the Websphere MQ implementation jar into tomcat/lib.

Of course, that meant that the war file was no longer really a complete unit of deployment. Instead, deployment was a two-step process. It's a trade-off. I thought this was easier than managing multiple war file build variants, each bundling a different JMS provider jar.