GlassFish equivalent to WebSphere’s “shared libraries”
December 16, 2008 § 6 Comments
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.
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.
Regards,
Alexandre
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.
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.
Thanks Sahoo. This approach uses the Application class-loader and can be expressed using application.xml.
So this is also a relevant source: http://blogs.oracle.com/sivakumart/entry/classloaders_in_glassfish_an_attempt
Can you add this info to the migration guide?
http://wiki.glassfish.java.net/Wiki.jsp?page=M2GMigrationGuide
Done!