Application-related differences exist between GlassFish Server 3.0.1 and GlassFish Server v2. This section describes some of those differences.
The default value of the force option for deployment is false in GlassFish Server 3.0.1. This default value was true in GlassFish Server v2. In GlassFish Server 3.0.1 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 GlassFish Server 3.0.1 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.
GlassFish Server v2 contained two subdirectories for the applications repository: applications/j2ee-apps and applications/j2ee-modules. Those subdirectories no longer exist in GlassFish Server 3.0.1 (there is no j2ee-apps or j2ee-modules level). Deployment of a standalone module such as foo.war, which was previously located in applications/j2ee-modules/foo in GlassFish Server v2, is now located in applications/foo in GlassFish Server 3.0.1. Enterprise applications and standalone modules essentially share the same name space, so the intermediate directory layer was not necessary.
Previous elements such as web-module, ejb-module, and so on are deprecated in GlassFish Server 3.0.1 and replaced with the new application element. For more information about the application element, see application in Oracle GlassFish Server 3.0.1 Domain File Format Reference.
During an upgrade, GlassFish Server v2 applications are redeployed at the new applications/ location with the new application element in domain.xml. Any new applications deployed on GlassFish Server 3.0.1 will be deployed with the new directory structure and element.
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.
In Oracle GlassFish Server 3.0.1, running the deploy --retrieve and get-client-stubs commands no longer downloads just one JAR file to your local directory as in GlassFish Server v2. While localdir/myAppClient.jar is still created in GlassFish Server 3.0.1 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 GlassFish Server v2 downloaded JAR file as a way to move the application client components from one place to another, that will not work in GlassFish Server 3.0.1. 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 GlassFish Server v2), but also all of the contents of the localdir/myAppClient directory.