Skip to main content

WebLogic to GlassFish : Sharing classes using APP-INF

Posted by sekhar on March 23, 2009 at 12:31 PM PDT

Migration Issue:

WebLogic application server supports sharing of utility classes
in an ear file. The shared utility classes can be packaged in one
of two directories :

  • APP-INF/lib : shared jar files can be placed here.
  • APP-INF/classes : individual classes can be placed here.

The problem is that APP-INF is proprietary to WebLogic and non
portable.

Migration Path to GlassFish:

Use the portable mechanism for sharing introduced in Java EE 5 specification. Java EE specification defines the following.

"A .ear file may contain a directory that contains libraries
packaged in JAR files. The library-directory element of the
.ear file's deployment descriptor contains the name of this
directory. If a library-directory element isn't specified, or
if the .ear file does not contain a deployment descriptor, the
directory named lib is used. An empty library-directory element
may be used to specify that there is no library directory.

All files in this directory (but not subdirectories) with a
.jar extension must be made available to all components
packaged in the EAR file, including application clients. These
libraries may reference other libraries, either bundled with
the application or installed separately, using any of the
techniques described herein."

To migrate a shared jar file, foo.jar packaged in
APP-INF/lib/foo.jar, do one of the following:

  • move APP-INF/lib/foo.jar to lib/foo.jar .
  • use element in META-INF/application.xml to reference the current location where the shared jar files are packaged.
    <application>
       <library-directory>APP-INF/lib</library-directory>
    </application>
        

Note that the is new for Java EE 5 and is
defined by the XML Schema for Version 5 of application.xml (
http://java.sun.com/xml/ns/javaee/application_5.xsd ). The
META-INF/application.xml being migrated might contain the DTD for the
older version of application.xml. In this case, replace the DTD with
the following:

 <application version="5" xmlns="http://java.sun.com/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
              " title="http://java.sun.com/xml/ns/javaee/application_5.xsd">">http://java.sun.com/xml/ns/javaee/application_5.xsd">

Otherwise, the deployment will fail with the following error in
server.log.

Deploying application in domain failed; Deployment descriptor file META-INF/application.xml in archive [archive-file-name]. Element type "library-directory" must be declared.

To migrate shared individual classes in APP-INF/classes, package
the classes into a jar file and add them to the lib
directory.

Related Topics >>

Comments

Hi, Yes, the security part is for example the one we were talking about in that message. It's an old pet peeve of mine since version 2.3 of the servlet spec. (Java EE security basically followed the same principles). Regarding security, having to specify the URL<->Roles mapping on a static descriptor, IMHO, falls quite short for an "enterprise" spec. as you have to resort to mix security with your business logic using isUserInRole() to check for dynamic roles (security that depends on the parameters of the request, some dynamic part of the URL or some other non-static factor). And on top of that, leaving the mapping of User<-> Roles "up to the container vendor" forces non-portable solutions, as confirmed by the number of different an incompatible "Database Security Realm" implementations that each container provides, all of them non-portable across containers. So if you "follow the spec.", regarding security, you are forced to mix concerns and create a not fully portable application.

Regarding the datasource, and maybe other JNDI resources, one simply needs to check the installation instructions of a popular Java EE application like JIRA to see that we have a problem :).

Each container has its own small quirck and there's no way for an application to specify "standard" datasource, even if all of them use basically the same data (data for the connection string, driver class, JNDI name). In both cases, I understand there might be applications/setting that don't need it or even require some of this features to be like that (like not allowing an application to specify a custom datasource itself), but this is the spec. we are talking about, it should cover all the reasonable scenarios, and I think there is ample proof that many Java EE applications would benefit from that. I'll send this message also to the address you mention, but last time I did something like that, the only answer I got back was "the Internet echo" (nothing) ;), so that's why I lately favour blogs/forums over email addresses that you never know if they reach anybody/who they reach/will the message simply be "lost"? Thanks for listening :)

greeneyed: Please send your feedback on the issues you have brought up to javaee-spec-feedback@sun.com . We are always interested in your your feedback !

Thanks for the feedbck ! Can you elaborate on " dynamic/portable security or naming/definition ?" I searched the GlassFish forum and did find your post to the GlassFish forum http://forums.java.net/jive/message.jspa?messageID=337626#337626 . Is this the dynamic security you are talking about or something else ?

It's nice to see this kind of non-portable issues being addressed in the spec. I wish others like dynamic/portable security or datasource naming/definition would also be dealt with... :(