Cambios relacionados con las aplicaciones

Existen diferencias en lo que se refiere a las aplicaciones entre Enterprise Server v3 y Enterprise Server v2. En esta sección se describen algunas de dichas diferencias.

Opción force

El valor predeterminado de la opción force para una implementación es falso en Enterprise Server v3. Este valor predeterminado era verdadero en Enterprise Server v2. En Enterprise Server v3 debe establecer explícitamente la opción en verdadero para la reimplementación. Esta opción no se establece automáticamente durante el proceso de actualización. La finalidad de este cambio es evitar sobrescribir accidentalmente el contenido de una aplicación existente. Esto se aplica tanto a la Consola de administración como a la utilidad de línea de comandos.

El comando reimplementación de asadmin también es nuevo en Enterprise Server v3 y le ofrece un equivalente a --force=verdadero. La opción force sólo se aplica al comando implementar (interfaz de línea de comandos) y a la pantalla implementar (consola), no al comando reimplementar ni a la pantalla reimplementar.

Diseño de directorios generados y aplicaciones

Enterprise Server v2 incluía dos subdirectorios para el depósito de aplicaciones: applications/j2ee-apps y applications/j2ee-modules. Estos subdirectorios no existen en Enterprise Server v3 (no hay ningún nivel j2ee-apps ni j2ee-modules). La implementación de un módulo independiente como, por ejemplo, foo.war, que se encontraba en applications/j2ee-modules/foo en Enterprise Server v2, se encuentra ahora en applications/foo en Enterprise Server v3. Las aplicaciones de empresa y los módulos independientes comparten básicamente el mismo espacio de nombre, por lo que no se necesita la capa de directorio intermedio.

Elemento de aplicación domain.xml

Los elementos anteriores como, por ejemplo, web-module, ejb-module, etc., no han sido aprobados en Enterprise Server v3 y se han sustituido por el nuevo elemento de aplicación. Para obtener más información sobre el elemento de aplicación, consulte application de Sun GlassFish Enterprise Server v3 Domain File Format Reference.

Durante una actualización, las aplicaciones de Enterprise Server v2 se vuelven a implementar en la nueva ubicación applications/ con el nuevo elemento aplicación en domain.xml. Cualquier nueva aplicación implementada en Enterprise Server v3 se implementará con la nueva estructura de directorios y elemento.

Reglas de visibilidad de JAR más estrictas

Java EE 6 impone reglas de visibilidad de JAR más estrictas que Java EE 5. Como resultado, puede que fallen algunas aplicaciones anteriores.

La especificación de Java EE 6 impone reglas estrictas sobre qué archivos JAR se visualizan desde un archivo Enterprise Archive (EAR) (archivo de empresa). Consulte en particular la sección EE.8.3.3. En concreto, los módulos de cliente de aplicación no deben tener acceso a ningún archivo JAR EJB a menos que el manifiesto de archivos JAR del cliente de la aplicación Class-Path haga referencia explícitamente a los archivos JAR EJB.

Este es un cambio con respecto a Enterprise Server v2, en el que los clientes de aplicaciones tenían acceso automáticamente a todos los archivos EJB JAR del archivo EAR y a todos los archivos JAR del nivel superior del archivo EAR. Para ser acorde con el idioma de especificación más estricto, Enterprise Server v3 no puede proporcionar automáticamente clientes de aplicaciones con acceso a estos archivos JAR.

Este nuevo comportamiento más estricto que impone Java EE 6 se puede gestionar del siguiente modo:

• Si la aplicación está implementada en un dominio de Enterprise Server v2, la Herramienta de actualización conservará el comportamiento de Enterprise Server v2 para dicha aplicación de ese dominio. Para obtener más información sobre la actualización, consulte la Sun GlassFish Enterprise Server v3 Upgrade Guide .

• Cambie el manifiesto Class-Path del cliente para que haga referencia explícitamente a los archivos JAR de los que depende. Class-Path no debe enumerar los archivos JAR del directorio de la biblioteca de archivos EAR. Tal como se requiere en la especificación, todos los archivos JAR de ese directorio están disponibles para todos los módulos del archivo EAR. De forma predeterminada, este directorio es /lib, o se puede establecer en algún otro directorio mediante library-directory en el descriptor de application.xml.

• Implemente el archivo EAR utilizando el valor opcional --compatibilidad de propiedad=v2. Esto preserva el comportamiento de Enterprise Server v2 para dicha aplicación cuando se implemente en Enterprise Server v3.

Este cambio de comportamiento se analiza también en el Capítulo 1, Application Server Compatibility Issues de Sun GlassFish Enterprise Server v3 Upgrade Guide.

Comandos del cliente de aplicación deploy --retrieve y get-client-stubs

En Sun GlassFish Enterprise Server v3, al ejecutar los comandos deploy --retrieve y get-client-stub, ya no se descarga un sólo archivo JAR en el directorio local como en Enterprise Server v2. A pesar de que se sigue creando localdir/myAppClient.jar en Enterprise Server v3 y se puede utilizar como destino en el comando appclient, también se crea otro directorio, localdir/myAppClient , que puede contener otros archivos.

Si normalmente copia el único archivo JAR descargado de Enterprise Server v2 para trasladar los componentes de clientes de aplicaciones de un lugar a otro, esto no funcionará en Enterprise Server v3. El método admitido es usar el comando asadmin get-client-stubs para dicho fin. Para obtener más información sobre el comando, consulte get-client-stubs(1).

No obstante, si aún decide realizar la copia, debe copiar no sólo el archivo localdir/myAppClient.jar (como en Enterprise Server v2), sino también todo el contenido del directorio localdir/myAppClient.