mercredi décembre 17, 2008 
mercredi décembre 17, 2008 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.
( déc. 17 2008, 07:03:00 AM CET ) Permalink Comments [6]Post a Comment:
Comments are closed for this entry.
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
Posted by Alexandre Touret on décembre 17, 2008 at 10:38 AM CET #
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.
Posted by Alexis MP on décembre 17, 2008 at 11:11 AM CET #
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.
Posted by sahoo on décembre 17, 2008 at 07:07 PM CET #
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.sun.com/sivakumart/entry/classloaders_in_glassfish_an_attempt
Posted by Alexis MP on décembre 17, 2008 at 07:47 PM CET #
Can you add this info to the migration guide?
http://wiki.glassfish.java.net/Wiki.jsp?page=M2GMigrationGuide
Posted by John Clingan on décembre 18, 2008 at 01:17 AM CET #
Done!
Posted by Alexis MP on décembre 18, 2008 at 10:38 AM CET #