Changes Related to Applications

Application-related differences exist between Enterprise Server v3 and Enterprise Server v2. This section describes some of those differences.

force Option

The default value of the force option for deployment is false in Enterprise Server v3. This default value was true in Enterprise Server v2. In Enterprise Server v3 you must explicitly set the option to true for redeployment. This option is not automatically set during the upgrade process. The purpose of this change is to avoid accidentally overwriting the contents of an existing application. This applies to both the Administration Console and command-line utility.

The asadmin redeploy command is also new in Enterprise Server v3 and offers an equivalent to --force=true. The force option is only applicable to the deploy command (command-line interface) and the deploy screen (console), not to the redeploy command and redeploy screen.

Applications and Generated Directory Layout

Enterprise Server v2 contained two subdirectories for the applications repository: applications/j2ee-apps and applications/j2ee-modules. Those subdirectories do not exist in Enterprise Server v3 (there is no j2ee-apps or j2ee-modules level). Deployment of a standalone module such as foo.war, which resided in applications/j2ee-modules/foo in Enterprise Server v2, now resides in applications/foo in Enterprise Server v3. Enterprise applications and standalone modules essentially share the same name space, so the intermediate directory layer was not necessary.

domain.xml application Element

Previous elements such as web-module, ejb-module, and so on are deprecated in Enterprise Server v3 and replaced with the new application element. For more information about the application element, see application in Sun GlassFish Enterprise Server v3 Domain File Format Reference.

During an upgrade, Enterprise Server v2 applications are redeployed at the new applications/ location with the new application element in domain.xml. Any new applications deployed on Enterprise Server v3 will be deployed with the new directory structure and element.

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. See especially 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 Enterprise 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, Enterprise Server v3 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 an Enterprise Server v2 domain, Upgrade Tool will preserve the Enterprise Server v2 behavior for that application in that domain. For more information about upgrading, see Sun GlassFish Enterprise Server v3 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 Enterprise Server v2 behavior for that application when it is deployed to Enterprise Server v3.

This change in behavior is also discussed in Chapter 1, Application Server Compatibility Issues, in Sun GlassFish Enterprise Server v3 Upgrade Guide.

Application Client deploy --retrieve and get-client-stubs Commands

In Sun GlassFish Enterprise Server v3, running the deploy --retrieve and get-client-stubs commands no longer downloads just one JAR file to your local directory as in Enterprise Server v2. While localdir/myAppClient.jar is still created in Enterprise Server v3 and can be used as a target in the appclient command, another directory is also created, localdir/myAppClient, which in turn might contain other files.

If you typically copy the single Enterprise Server v2 downloaded JAR file as a way to move the application client components from one place to another, that will not work in Enterprise Server v3. The supported method is to use the asadmin get-client-stubs command for that purpose. For more information about the command, see get-client-stubs(1).

If you still choose to copy, however, you must copy not only the localdir/myAppClient.jar file (as in Enterprise Server v2), but also all of the contents of the localdir/myAppClient directory.