donderdag 29 juli 2010

ear deployment on glassfish 3 (vs glassfish 2)

I recently had some trouble deploying an ear file to the new glassfish v3. It works on glassfish v2. After some investigation I found that the way the ejb's were located in the ear file was not accepted by version 3 of the glassfish application server.

In short the jar files on the top level of the ear package are no longer visible by default. You need to put libraries, available to all modules of the package into the default lib folder. Or you'll have to add their location to the manifest file (Class-Path)

With maven you can set the class-path to a manifest file with the defaultLibBundleDir tag and you can put modules/dependencies in other locations with the manifestEntries tag. An example:


<build>
 <plugins>
  <plugin>
   <artifactId>maven-ear-plugin</artifactId>
   <version>2.4.2</version>
   <configuration>
    <!-- required since glassfish v3 -->
    <defaultLibBundleDir>lib</defaultLibBundleDir>
    <archive>
     <manifestEntries>
      <Class-Path>YOUR_VALUES_HERE</Class-Path>
     </manifestEntries>
    </archive>

You can read about this in detail at the following link: http://docs.sun.com/app/docs/doc/821-1759/ggpnv?l=en&a=view

Stricter JAR Visibility Rules


Java EE 6 imposes stricter JAR visibility rules than did Java EE 5.
As a result, some older applications might fail.

The Java
EE 6 specification
imposes strict rules about which JAR files are
visible from an enterprise archive (EAR) file. Refer to section EE.8.3.3;
specifically, application client modules should not have access to any EJB
JAR file unless the application client JAR file's manifest Class-Path refers to the EJB JAR file(s) explicitly.

This is a change from GlassFish Server v2, in which application clients
automatically had access to all EJB JAR files in the EAR file and all JAR
files at the top level of the EAR file. To comply with the stricter specification
language, GlassFish Server 3.0.1 cannot automatically provide application
clients with access to these JAR files.

This new, stricter behavior imposed by Java EE 6 can be addressed as
follows:


  • If the application is deployed to a GlassFish Server v2 domain,
    Upgrade Tool will preserve the GlassFish Server v2 behavior for that application
    in that domain. For more information about upgrading, see Oracle GlassFish Server 3.0.1 Upgrade Guide.
  • Change the manifest Class-Path of the client
    so it refers explicitly to the JAR files on which it depends. The Class-Path must not list JAR files in the EAR file's library directory. As
    required by the specification, all JAR files in that directory are available
    to all modules in the EAR file. This directory is /lib by
    default, or can be set to some other directory using library-directory in
    the application.xml descriptor.
  • Deploy the EAR file using the optional --property
    compatibility=v2
    setting. This preserves the GlassFish Server v2 behavior
    for that application when it is deployed to GlassFish Server 3.0.1.

This change in behavior is also discussed in Chapter 1, GlassFish Server Compatibility Issues, in Oracle GlassFish Server 3.0.1 Upgrade Guide.

Geen opmerkingen:

Een reactie plaatsen