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.

Answer 2

Is there some best practice or official document that talks about this issue?

I doubt you will find official documents (from the Tomcat developers/community) to support this theory, although it is very valid. I had to prepare one in my previous job, so that the EAR file of the application could be deployed across multiple J2EE containers.

There is one thing in favour though. You can bring up the IBM Redbook titled "WebSphere Application Server V6.1: Classloader Problem Determination" (quite dated, given that WAS 7 is available) which demonstrates how to created shared libraries in WebSphere. On WebSphere, one can create multiple such libraries for applications that require differing versions. On Tomcat, you are the mercy of an administrator who may not know what a class loader is, given that all shared libraries is dumped into $CATALINA_HOME\\lib .

The Redbook also has this bit of advice (replace utility file with utility JAR and you have your answer):

Where you should not place utility files

In deciding where best to place your utility files, it is important to recognize that these files should not be included in the WebSphere Application Server's environment.

For example: app_server_root/lib, app_server_root/lib,/ext* , app_server_root/java (including any subdirectories), or the JVM classpath.

Adding utility files to those directories can cause problems with the WebSphere runtime environment and can cause unexpected results, including the overwriting of WebSphere classes that can be detrimental to the overall functionality of the server.

Answer 3

I would go for Optional Packages: http://docs.oracle.com/javase/6/docs/technotes/guides/extensions/index.html

Steps:

1. Package your code, libraries in a jar/war.

2. In the MANIFEST.MF of the above declare the extension list jars

3. Referred them in the target applications