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 appli

Answer 1

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

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

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.