GlassFish equivalent to WebSphere's "shared libraries"

Shared Libraries is a feature that allows WebSphere users to deploy applications libraries (frameworks, ...).

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

Based on previous experiences with additional libraries in the JDK, some users have 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.

Multiple versions of libraries

One can 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.

(from http://blogs.oracle.com/alexismp/entry/glassfish_equivalent_to_websphere_s)