Application Client Interoperability

The Java EE 6 platform specification imposes stricter requirements than Java EE 5 did on which JAR files can be visible to various modules within an EAR file. In particular, application clients must not have access to EJB JAR files or other JAR files in the EAR file unless they use a Class-Path header in the manifest file, or unless references use the standard Java SE mechanisms (extensions, for example), or use the Java EE library-directory mechanism. Deployed Java EE 5 applications that are upgraded to GlassFish Server 3.1 will have the compatibility property set to v2 and will run without change on GlassFish Server 3.1. You may, however, want to consider modifying the applications to conform to Java EE 6 requirements.

If your upgrade includes a deployed application with an application client, you will need to retrieve the client stubs using GlassFish Server 3.1 in order to run the client. Use the asadmin get-client-stubs command.

If you try to run the application client before retrieving the client stubs, you will see the following error message:

Invalid or corrupt jarfile jar-file-name

If you commonly distribute application clients to remote systems from which users will run them, you must not only retrieve the client stubs, but you must also run the package-appclient utility for GlassFish Server 3.1 to upgrade the GlassFish Server system files. This utility creates a JAR file, which you can then expand on the remote systems.

Application clients use EJBs, web services, or other enterprise components that are in the application server (on the server side). The application client and the application server must use the same version and implementation of the RMI-IIOP protocol. GlassFish Server 3.1 does not support communication between different versions of the protocol implementation. You cannot run application clients with one version of the application server runtime with a server that has a different version. Most often, this would happen if you upgraded the server but had not upgraded all the application client installations. If you run the package-appclient utility, this issue will not arise.

You can use the Java Web Start support to distribute and launch the application client. If the runtime on the server has changed since the end-user last used the application client, Java Web Start automatically retrieves the updated runtime. Java Web Start enables you to keep the clients and servers synchronized and using the same runtime.