Alterações relativas aos aplicativos

As diferenças relativas ao aplicativo existem entre o Enterprise Server v3 e o Enterprise Server v2. Esta seção descreve algumas destas diferenças.

Opção force

O valor padrão da opção force para a implementação é false no Enterprise Server v3. O valor padrão era true no Enterprise Server v2. No Enterprise Server v3 é preciso definir explicitamente a opção como true para a reimplementação. Esta opção não é automaticamente definida durante o processo de atualização. O propósito desta alteração é a de evitar sobrescrever acidentalmente o conteúdo de um aplicativo existente. Isso se aplica ao Console de Administração e ao utilitário de linha de comando.

O comando asadmin redeploy também é novo no Enterprise Server v3 e oferece um equivalente para --force=true. A opção force somente é aplicável ao comando deploy (interface da linha de comando) e a tela deploy (console), não para o comando redeploy e para a tela redeploy.

Aplicativos e o layout do diretório gerado

O Enterprise Server v2 continha dois subdiretórios para o repositório do aplicativo: applications/j2ee-apps e applications/j2ee-modules. Estes subdiretórios não existem no Enterprise Server v3 (não há nenhum nível j2ee-apps ou j2ee-modules). A implementação de um módulo independente como o foo.war, que residia no applications/j2ee-modules/foo no Enterprise Server v2, agora reside no applications/foo no Enterprise Server v3. Os aplicativos corporativos e os módulos independentes, compartilham essencialmente o mesmo espaço de nome, portanto, a camada de diretório intermediário não era necessária.

Elemento do aplicativo domain.xml

Elementos anteriores como o web-module, ejb-module , e assim por diante, são desaconselhados no Enterprise Server v3 e são substituídos com o novo elemento aplicativo. Para obter mais informações sobre o elemento aplicativo, consulte application no Sun GlassFish Enterprise Server v3 Domain File Format Reference.

Durante uma atualização, os aplicativos do Enterprise Server v2 são reimplementados na nova localização applications/ com o novo elemento aplicativo no domain.xml. Quaisquer novos aplicativos implementados no Enterprise Server v3, serão implementados com a nova estrutura de diretório e elemento.

Regras mais estritas de visibilidade JAR

O Java EE 6 impõe regras mais estritas de visibilidade JAR do que o Java EE 5 fazia. Como resultado, alguns aplicativos mais antigos podem falhar.

A especificação Java EE 6 impõe regras estritas sobre quais arquivos JAR são visíveis de um arquivo corporativo (EAR). Consulte especialmente a seção EE.8.3.3. Especificamente, os módulos de aplicativo cliente não deveriam ter acesso à qualquer arquivo EJB JAR, a não ser que o manifesto do arquivo JAR do aplicativo cliente Class-Path se refira explicitamente ao arquivo EJB JAR.

Esta é uma alteração do Enterprise Server v2, no qual o aplicativo cliente tinha o acesso automático à todos os arquivos EJB JAR no arquivo EAR e a todos os arquivos JAR no nível superior do arquivo EAR. Para estar em conformidade com a linguagem com especificação mais estrita, o Enterprise Server v3 não pode fornecer automaticamente aplicativos clientes com acesso ao arquivos JAR.

Este novo comportamento mais estrito imposto pelo Java EE 6 pode ser endereçado como segue:

• Se o aplicativo está implementado para um domínio do Enterprise Server v2, a Ferramenta de Atualização irá preservar o comportamento do Enterprise Server v2 para aquele aplicativo naquele domínio. Para obter mais informações sobre como atualizar, consulte o Sun GlassFish Enterprise Server v3 Upgrade Guide.

• Altere o manifesto Class-Path do cliente, para que ele se refira explicitamente aos arquivos JAR does quais ele depende. O Class-Path não pode listar os arquivos JAR no diretório da biblioteca dos arquivos EAR. Como requerido pela especificação, todos os arquivos JAR naquele diretório estão disponíveis para todos os módulos no arquivo EAR. Este diretório é o /lib por padrão, ou pode ser definido para algum outro diretório usando library-directory no descritor application.xml.

• Implemente o arquivo EAR usando a configuração opcional --property compatibility=v2. Isso preserva o comportamento do Enterprise Server v2 para aquele aplicativo quando ele é implementado no Enterprise Server v3.

Esta alteração de comportamento também é discutida no Capítulo 1, Application Server Compatibility Issues, no Sun GlassFish Enterprise Server v3 Upgrade Guide.

Comandos deploy --retrieve e get-client-stubs do aplicativo cliente

No Sun GlassFish Enterprise Server v3, a execução dos comandos deploy --retrieve e get-client-stubs , não mais baixa somente um arquivo JAR para seu diretório local como fazia no Enterprise Server v2. Embora o localdir/myAppClient.jar ainda é criado no Enterprise Server v3 e pode ser usado como um destino no comando appclient . outro diretório também é criado, localdir/myAppClient , que por sua vez pode conter outros arquivos.

Se você normalmente copia o arquivo JAR único baixado do Enterprise Server v2, como uma forma de mover os componentes do aplicativo cliente de um lugar para outro, isso não irá funcionar no Enterprise Server v3. O método suportado é o de usar o comando asadmin get-client-stubs para aquele propósito. Para obter mais informações sobre o comando, consulte get-client-stubs(1).

Se você ainda escolhe copiar, no entanto, precisa copiar não somente o arquivo localdir/myAppClient.jar (como no Enterprise Server v2), mas também todo o conteúdo do diretório localdir/myAppClient.