Sharing open source (Spring/Spring Security/Hibernate/etc) jars across web applications

4
votes

We have a bunch of Java EE applications based on open source frameworks such as mentioned above. The WEB-INF/lib for each application has the following common jars:

antlr-2.7.6.jar*
aopalliance-1.0.jar*
asm-3.3.1.jar*
aspectjrt-1.6.8.jar*
aspectjweaver-1.6.8.jar*
cglib-2.2.jar*
commons-beanutils-1.8.3.jar*
commons-collections-3.1.jar*
commons-dbcp-1.4.jar*
commons-digester-2.1.jar*
commons-fileupload-1.1.1.jar*
commons-io-2.0.1.jar*
commons-logging-1.1.1.jar*
commons-pool-1.5.6.jar*
dom4j-1.6.1.jar*
hibernate-jpa-2.0-api-1.0.0.Final.jar*
hibernate-tools.jar*
hibernate-validator-4.1.0.Final.jar*
hibernate3.jar*
jackson-all-1.7.5.jar*
javassist-3.12.0.GA.jar*
javax.inject.jar*
log4j-1.2.16.jar*
org.springframework.aop-3.0.5.RELEASE.jar*
org.springframework.asm-3.0.5.RELEASE.jar*
org.springframework.beans-3.0.5.RELEASE.jar*
org.springframework.context-3.0.5.RELEASE.jar*
org.springframework.context.support-3.0.5.RELEASE.jar*
org.springframework.core-3.0.5.RELEASE.jar*
org.springframework.expression-3.0.5.RELEASE.jar*
org.springframework.jdbc-3.0.5.RELEASE.jar*
org.springframework.orm-3.0.5.RELEASE.jar*
org.springframework.transaction-3.0.5.RELEASE.jar*
org.springframework.web-3.0.5.RELEASE.jar*
org.springframework.web.servlet-3.0.5.RELEASE.jar*
poi-3.7-20101029.jar*
slf4j-api-1.6.1.jar*
slf4j-ext-1.6.1.jar*
slf4j-log4j12-1.6.1.jar*
spring-security-acl-3.0.5.RELEASE.jar*
spring-security-aspects-3.0.5.RELEASE.jar*
spring-security-config-3.0.5.RELEASE.jar*
spring-security-core-3.0.5.RELEASE.jar*
spring-security-taglibs-3.0.5.RELEASE.jar*
spring-security-web-3.0.5.RELEASE.jar*
testng-6.0.1.jar*
tiles-api-2.2.2.jar*
tiles-core-2.2.2.jar*
tiles-jsp-2.2.2.jar*
tiles-servlet-2.2.2.jar*
tiles-template-2.2.2.jar*
validation-api-1.0.0.GA.jar*

We are experiencing permgen errors on deploy, each war is a little of 20 MB with 3rd party jars being the bulk.

Since all the applications are on the same version for all open source projects I am wondering if it is going to be okay if I move Spring, Spring Security, Spring Tiles, Hibernate, Hibernate related 3rd party jars (cglib, antlr, etc), logging and apache-commons.* to TOMCAT/lib folder.

I remember from Struts days (2003 or 2004) each web-app was supposed to have it's own copy of struts' jars and sharing on the application server level was discouraged. Does any such discouragement (apart from versioning) apply?

As an auxiliary question: is there a general rule to follow which 3rd party jars can be or cannot be shared (if not clearly mentioned in the docs?

I'll appreciate any help. Thank you.

1
hibernatespringjakarta-eetomcatclassloader
log4j should definately go in each WAR, if you package log4g.properties also for each WAR (e.g. you have separate logfiles for each web application). Otherwise (if you have app-server wide log4g.properties) you can put log4j into app-server libs/. Note that if there are memory leaks in one of the frameworks (e.g. via static variables), it will impact you app server in a whole. - dma_k
Good point about memory leak. - kmansoor

1 Answers

3
votes

Depending on how you bootstrap your application, you could probably move most (or all) of those jars (test it and find out). What you need to be careful with are frameworks that rely on bootstrapping from static initializers. If I recall correctly, Struts configured itself from a static initializer that read the struts-config file. Since the static initializer only runs the first time a class is loaded, it would not work well in shared classloaders.

More to the point, your problem might not end with just moving the jars to the shared loader. Spring and Hibernate will create a LOT of dynamic classes at runtime for entities and AOP proxies (for transaction support etc) which will reside in the permanent generation. It's usual that for application that are heavy on Spring and Hibernate, you will have to increase the permgen space (via the -XX:MaxPermSize parameter on Oracle HotSpot VM, for instance).