GlassFish equivalent to WebSphere’s “shared libraries”

With migration opportunities from other application servers to GlassFish popping up here and there, I was recently asked how to deal with WebSphere shared libraries in GlassFish.

Common Class Loader
GlassFish v2 has a well defined Class Loader hierarchy which identifies the common class loader as the proper way to deal with shared libraries. So to make a long story short, putting you libraries and other framework JARs in domains/domain1/lib is all you need to do.

lib/, not lib/ext
The person asking me the question had tried putting the libraries in domains/domain1/lib/ext which triggered an interesting ClassNotFoundError for core Java EE classes such as javax.servlet.http.HttpServlet. Shing Wai Chan was quick to explain that domains/domain1/lib/ext is part of -Djava.ext.dirs which makes any of its JARs be considered as a JDK extension which means web app frameworks placed there will be loaded before webcontainer implementation classes as they are higher up in the classloader delegation chain.

Update: make sure you read the comments for additional suggestions from Sahoo and John.

Author: alexismp

Google Developer Relations in Paris.

6 thoughts on “GlassFish equivalent to WebSphere’s “shared libraries””

  1. Hello
    In my opinion, one of the weakness of both glassfish and jboss as is shared lib. You can use domain/lib to put shared libraries but you can release a shared lib and use a release (eg. lib v 1.0) for an app and a former release for an another app (eg. v 0.2)
    I can do this with OC4J, WAS and WLS.

  2. One can of course bundle libraries in the deployment archive, but that’s not an elegant solution. The real solution lies IMO in a 1st class modules system such as OSGi.

  3. It is possible to use different versions of libraries by different applications in Glassfish without bundling such libraries in the applications. See "–libraries" option while deploying. So, you can do this:
    copy lib_1_0.jar lib_2_0.jar domain1/lib/applibs/
    asadmin deploy –libraries lib_1_0.jar app1.ear
    asadmin deploy –libraries lib_1_0.jar app2.war
    asadmin deploy –libraries lib_2_0.jar app3.jar
    asadmin deploy –libraries lib_2_0.jar app4.ear
    In the above example, app1.ear and app2.war use lib_1_0.jar where as app3.jar and app4.ear use lib_2.0.jar.

Comments are closed.