GlassFish equivalent to WebSphere's "shared libraries"

This blog has moved to alexismp.wordpress.com
Follow the link for the most up-to-date version of this blog entry.

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.

Comments:

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 02: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 03: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 11:07 AM 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 11:47 AM 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 17, 2008 at 05:17 PM CET #

Done!

Posted by Alexis MP on décembre 18, 2008 at 02:38 AM CET #

Post a Comment:
Comments are closed for this entry.
About

This blog has moved

Alexis Moussine-Pouchkine's Weblog

GlassFish - Stay Connected

Search

Archives
« avril 2014
lun.mar.mer.jeu.ven.sam.dim.
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today
Blogroll

No bookmarks in folder

News

No bookmarks in folder