Guia de Migração
Para uso com o JBoss Enterprise Application Platform 6
Red Hat Customer Content Services
Resumo
Capítulo 1. Introdução
1.1. Red Hat JBoss Enterprise Application Platform 6
1.2. Guia da Migração
Capítulo 2. Preparação para a Migração
2.1. Preparação para a Migração
Revisão das novidades no JBoss EAP 6
Diversas modificações foram realizadas neste lançamento que podem impactar na implantação dos aplicativos do EAP 5. Isto inclui modificações à estrutura do diretório do arquivo, configuração da implantação, carregamento da classe e pesquisas JNDI. Consulte a Seção 2.2, “Revisão das novidades no JBoss EAP 6” para maiores detalhes.Revisão da documentação da Inicialização
Certifique-se de revisar o capítulo nomeado Iniciação dos Aplicativos de Desenvolvimento no Guia de Desenvolvimento do JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/. Isto contém informações importantes sobre:- Java EE 6
- O novo sistema de carregamento de classe modular.
- Alterações da estrutura do arquivo.
- Como efetuar o download e instalar o JBoss EAP 6.
- Como baixar e instalar o JBoss Developer Studio.
- Como configurar o Maven para o seu ambiente de desenvolvimento.
- Como baixar e executar os aplicativo de amostra de iniciação rápida que lançam o produto.
Aprenda como usar as Dependências do JBoss EAP 6 em seu Projeto Maven
Certifique-se de rever o capítulo nomeado Guia do Maven no Guia de Desenvolvimento para o JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/. A seção Gerenciar as Dependências do Projeto contém informações importantes de como configurar o seu projeto para uso dos artefato do JBoss EAP Bill of Material (BOM).Análise e Entendimento de seu Aplicativo
Cada aplicativo é único e os componentes e a arquitetura do aplicativo existente devem ser entendidos por completo antes da migração ser realizada.
Importante
2.2. Revisão das novidades no JBoss EAP 6
Segue abaixo uma lista das diferenças visíveis no JBoss EAP 6 a partir do lançamento anterior.
- Módulo baseado no carregamento da classe
- No JBoss EAP 5, a arquitetura de carregamento de classe era hierárquico. No JBoss EAP 6, o carregamento de classe é baseado nos Módulos do JBoss. Isto oferece um isolamento do aplicativo verdadeiro, oculta as classes de implementação do servidor e apenas carrega as classes que seu aplicativo necessita. O carregamento de classe é para melhor desempenho. Os aplicativos gravados para o JBoss EAP 5 devem ser modificados para especificar as dependências e em alguns casos, arquivos de re-empacotamento. Para maiores informações, refira-se ao Carregamento de Classe e Módulos no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.
- Domain Management
- No JBoss EAP 6, o servidor pode ser executado como um servidor autônomo ou num managed domain. Num managed domain, você pode configurar todos os grupos dos servidores de uma só vez, mantendo as configurações sincronizadas por toda a rede de servidores. Enquanto isto não deve impactar os aplicativos construídos, isto pode simplificar o gerenciamento de implantações para servidores múltiplos. Refira-se ao Managed Domains no Guia de Configuração e Administração do JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.
- Configuração da Implantação
- Servidores Autônomos e Managed Domains
- O JBoss EAP 5 usava um perfil baseado na configuração de implantação. Esses perfis estavam localizados no diretório
EAP_HOME/server/
. Os aplicativos sempre continham arquivos de configuração múltiplos para segurança, banco de dados, adaptador de recurso e outras configurações. No JBoss EAP 6, a configuração da implantação é feita usando um arquivo. Esse arquivo é usado para configurar todos os serviços e subsistemas usados para a implantação. Um servidor autônomo é configurado usando o arquivoEAP_HOME/standalone/configuration/standalone.xml
. Para os servidores executando no managed domain, o servidor é configurado usando o arquivoEAP_HOME/domain/configuration/domain.xml
. A informação contida nos arquivos de configuração do JBoss EAP 5 deve ser integrada ao novo arquivo de configuração única. - Ordenação das implantações
- O JBoss EAP 6 usa uma rápida inicialização para a implantação, resultando num desempenho aprimorado e eficiente. Na maioria das vezes, o servidor do aplicativo está apto a determinar as dependências automaticamente com antecedência e escolher a estratégia de implantação mais eficiente. No entanto, os aplicativos do JBoss EAP 5, que consistem em módulos múltiplos implantados como EARs que usam pesquisas JNDI de legacia ao invés de injeção CDI ou entradas de referência de recurso, podem requerer alterações de configuração.
- Estrutura de Diretório e Scripts
- Conforme mencionado anteriormente, o JBoss EAP 6 não usa um perfil baseado na configuração da implantação, portanto não há diretório
EAP_HOME/server/
. Os arquivos de configuração para os servidores autônomos estão agora localizados no diretórioEAP_HOME/standalone/configuration/
e as implantações localizadas no diretórioEAP_HOME/standalone/deployments/
. Para servidores executando num managed domain, os arquivos de configuração podem ser encontrados no diretórioEAP_HOME/domain/configuration/
.No JBoss EAP 5, o script do LinuxEAP_HOME/bin/run.sh
ou o script do WindowsEAP_HOME/bin/run.bat
era usado para iniciar o servidor. No JBoss EAP 6, o script de iniciação do servidor depende de como você executa o seu servidor. O script do LinuxEAP_HOME/bin/standalone.sh
ou script do WindowsEAP_HOME/bin/standalone.bat
é usado para iniciar o servidor autônomo. O script do LinuxEAP_HOME/bin/domain.sh
ou o script do WindowsEAP_HOME/bin/domain.bat
é usado para iniciar um managed domain. - Pesquisas JNDI
- O JBoss EAP 6 usa agora JNDI namespaces portáveis padronizados. Os aplicativos gravados no JBoss EAP 5 que usam as pesquisas JNDI, devem ser alterados para seguir a nova convenção de JNDI namespace gerenciado. Para maiores informações sobre a sintaxe de nomeação JNDI, consulte a Seção 3.1.8.2, “Nomes do EJB JNDI Portátil ”.
2.3. Revisão da Lista de Recursos Substituídos e não Suportados
Capítulo 3. Migre seu Aplicativo
3.1. Alterações Requeridas para a maioria dos Aplicativos
3.1.1. Revisão das Alterações Requeridas para a Maioria dos Aplicativos
3.1.2. Alterações do Carregamento de Classe
3.1.2.1. Atualização do Aplicativo devido às Alterações do Carregamento da Classe
- Primeiro, observe o empacotamento de seu aplicativo e suas dependências. Consulte a: Seção 3.1.2.3, “Atualização das Dependências do Aplicativo devido às Alterações do Carregamento da Classe” para maiores informações.
- Caso o seu aplicativo realize o logon, será necessário especificar corretamente as dependências do módulo. Consulte a: Seção 3.1.4.1, “Modificação das Dependências de Registro em Log” para maiores informações.
- A estrutura do empacotamento de seu EAR ou WAR talvez precise ser alterada devido às alterações de carregamento de classe modular. Consulte a: Seção 3.1.5.1, “Modificação do Empacotamento dos EARS e WARs” para maiores informações.
3.1.2.2. Compreendendo as Dependências do Módulo
Um módulo é apenas apto a acessar suas próprias classes e as classes de qualquer módulo que possui uma dependência explícita ou implícita.
Procedimento 3.1. Compreendendo as Dependências do Módulo
Compreendendo as dependências implícitas
Os implantadores com o servidor adicionam automaticamente, e de forma implícita, algumas dependências de módulo comumente usadas como ojavax.api
esun.jdk
. Isto permite que as classes sejam visíveis à implantação no período de execução reduzindo a tarefa do desenvolvedor de adicionar explicitamente dependências. Consulte as Dependências de Módulo Implícitas no capítulo nomeado Carregamento de Carga e Módulo no Guia de Desenvolvimento para o JBoss EAP 6 https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/ para maiores informações.Compreendendo as dependências explícitas
Os módulos devem ser especificados explicitamente para outras classes, do contrário as dependências ausentes resultarão em implantação ou erros do período de execução. Caso falte uma dependência, traçosClassNotFoundExceptions
ouNoClassDefFoundErrors
poderão ser observados no log do servidor. Caso mais de um módulo carregar o mesmo JAR ou um módulo carregar uma classe que estende uma classe carregada por um módulo diferente, traçosClassCastExceptions
poderão ser vistos no servidor do log. Modifique oMANIFEST.MF
ou crie um arquivo do descritor de implantação específico do JBossjboss-deployment-structure.xml
para especificação explícita de dependências. Refira-se à Visão Geral do Carregamento de Classe e Módulos no capítulo nomeado Carregamento de Classe e Módulo no Guia de Desenvolvimento para o JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.
3.1.2.3. Atualização das Dependências do Aplicativo devido às Alterações do Carregamento da Classe
O carregamento de classe no JBoss EAP 6 é consideravelmente diferente do que as versões anteriores do JBoss EAP. O carregamento de classe é agora baseado no projeto de Módulos do JBoss. Ao invés de um único carregador de classe hierárquico que carrega todos os JARS num caminho de classe plano, cada biblioteca torna-se um módulo que apenas conecta os módulos extras dos quais ela depende. As implantações no JBoss EAP 6 são módulos e não precisam ter acesso às classes que são definidas nos JARs de um servidor de aplicativo, a não ser que uma dependência explícita seja definida nessa classe. Algumas das dependências do módulo definidas pelo servidor do aplicativo são configuradas automaticamente. Por exemplo: caso você esteja implantando um aplicativo Java EE, uma dependência no Java EE API é adicionada automaticamente ou implicitamente. Para uma lista de dependências adicionadas automaticamente pelo servidor, refira-se às Dependências de Módulo Implícitas no capítulo Carregamento de Classe e Módulos do Guia de Desenvolvimento para o JBoss Enterprise Application Plataform 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.
Quando você migrar seu aplicativo ao JBoss EAP 6, você pode precisar executar uma ou mais das seguintes tarefas devido às alterações do carregamento de classe modular:
3.1.3. Alterações do Arquivo de Configuração
3.1.3.1. Criação ou Modificação dos Arquivos que controlam o Controle de Carregamento da Classe no JBoss EAP 6
Devido à alteração no JBoss EAP 6 para uso do carregamento de carga modular, a modificação e criação de um ou mais arquivos possa ser necessária para adição de dependências ou para evitar que elas sejam carregadas. Refira-se ao capítulo Carregamento de Carga e Módulos do Guia de Desenvolvimento para o JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.
- jboss-web.xml
- Caso tenha definido um elemento
<class-loading>
no arquivojboss-web.xml
, será necessário removê-lo. O comportamento que isto causou no JBoss EAP 5 é agora o comportamento do carregamento da classe default no JBoss EAP 6, portanto ele não é mais necessário. Caso este elemento não seja mais removido, o ParseError e XMLStreamException serão exibidos no seu log do servidor.Segue abaixo uma amostra do elemento<class-loading>
no arquivojboss-web.xml
que encontra-se comentado.<!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 4.2//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_4_2.dtd"> <jboss-web> <!-- <class-loading java2ClassLoadingCompliance="false"> <loader-repository> seam.jboss.org:loader=MyApplication <loader-repository-config>java2ParentDelegation=false</loader-repository-config> </loader-repository> </class-loading> --> </jboss-web>
- MANIFEST.MF
- Editado manualmente
- Dependendo de quais componentes ou módulos o seu aplicativo usar, será necessário adicionar uma ou mais dependências a este arquivo. A adição das mesmas pode ser tanto como
Dependencies
ou como entradasClass-Path
.Segue abaixo uma amostraMANIFEST.MF
editada por um desenvolvedor:Manifest-Version: 1.0 Dependencies: org.jboss.logmanager Class-Path: OrderManagerEJB.jar
Caso deseje modificar esse arquivo, certifique-se de incluir um caractere com linha nova no final do arquivo. - Usando o Maven
- Caso use o Maven, será necessário modificar o seu arquivo
pom.xml
para gerar as dependências no arquivoMANIFEST.MF
. Caso seu aplicativo usar o EJB 3.0, uma seção no arquivopom.xml
poderá parecer-se com o seguinte:<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-ejb-plugin</artifactId> <configuration> <ejbVersion>3.0</ejbVersion> </configuration> </plugin>
Caso o código EJB 3.0 usar oorg.apache.commons.log
, será necessária aquela dependência no arquivoMANIFEST.MF
. Com o objetivo de gerar aquela dependência, adicione o elemento<plugin>
ao arquivopom.xml
, conforme abaixo:<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-ejb-plugin</artifactId> <configuration> <ejbVersion>3.0</ejbVersion> <archive> <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile> </archive> </configuration> </plugin>
Na amostra acima, o arquivosrc/main/resources/META-INF/MANIFEST.MF
precisa apenas conter a entrada da dependência:Dependencies: org.apache.commons.logging
O Maven gerará o arquivoMANIFEST.MF
completo:Manifest-Version: 1.0 Dependencies: org.apache.commons.logging
- jboss-deployment-structure.xml
- Esse arquivo é um descritor de implantação específico do JBoss que pode ser usado para controlar o carregamento da classe de forma granulada. Assim como o
MANIFEST.MF
, esse arquivo pode ser usado para adicionar dependência. Isto pode também prevenir que dependências automáticas sejam adicionadas, definir módulos adicionais, alterar o comportamento de carregamento da classe isolado da implantação EAR e adicionar raízes de recurso adicional ao módulo.Segue abaixo uma amostra do arquivojboss-deployment-structure.xml
que adiciona uma dependência para o módulo JSF 1.2 e previne o carregamento automático do módulo JSF 2.0.<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0"> <deployment> <dependencies> <module name="javax.faces.api" slot="1.2" export="true"/> <module name="com.sun.jsf-impl" slot="1.2" export="true"/> </dependencies> </deployment> <sub-deployment name="jboss-seam-booking.war"> <exclusions> <module name="javax.faces.api" slot="main"/> <module name="com.sun.jsf-impl" slot="main"/> </exclusions> <dependencies> <module name="javax.faces.api" slot="1.2"/> <module name="com.sun.jsf-impl" slot="1.2"/> </dependencies> </sub-deployment> </jboss-deployment-structure>
Consulte a: Seção 3.1.3.2, “jboss-deployment-structure.xml” para maiores informações sobre este arquivo. - application.xml
- Nas versões anteriores do JBoss EAP, a ordem das implantações com um EAR foi controlada usando o arquivo
jboss-app.xml
. Este não é mais o mesmo caso. O Java EE6 spec fornece o elemento<initialize-in-order>
noapplication.xml
que permite o controle da ordem pela qual os módulos do Java EE com um EAR são implantados.Na maioria das vezes, não é necessário especificar a ordem da implantação. Caso o seu aplicativo use injeções de dependência e referências de recurso para referenciar componentes em módulos externos, o elemento<initialize-in-order>
não é requerido na maioria das vezes, uma vez que o servidor do aplicativo está apto a determinar implicitamente a maneira correta e ideal de ordenar os componentes.Vamos assumir um aplicativo que contém ummyBeans.jar
e ummyApp.war
que são empacotado com omyApp.ear
. Um servlet nomyApp.war
usa uma anotação@EJB
para injetar um bean a partir domyBeans.jar
. Neste caso, o servidor do aplicativo possui o conhecimento apropriado para garantir que o componente EJB está disponível antes do servidor servlet ser iniciado, não havendo necessidade de usar o elemento<initialize-in-order>
.No entanto, caso o servlet usar referências remotas de estilo de pesquisa JNDI de legacia, conforme o seguinte, para acesso ao bean, a ordem do módulo talvez precise ser especificada.init() { Context ctx = new InitialContext(); ctx.lookup("TheBeanInMyBeansModule"); }
Neste caso, o servidor não está apto a determinar que o componente EJB está nomyBeans.jar
e será necessário que os componentes nomyBeans.jar
sejam inicializados e ativados antes dos componentes nomyApp.war
. Para isto, é necessário configurar o elemento<initialize-in-order>
paratrue
e especificar a ordem dos módulosmyBeans.jar
emyApp.war
no arquivoapplication.xml
.Segue abaixo uma amostra que usa o elemento<initialize-in-order>
para controlar a ordem de implantação. OmyBeans.jar
é implantado antes do arquivomyApp.war
.<application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="6" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_6.xsd"> <application-name>myApp</application-name> <initialize-in-order>true</initialize-in-order> <module> <ejb>myBeans.jar</ejb> </module> <module> <web> <web-uri>myApp.war</web-uri> <context-root>myApp</context-root> </web> </module> </application>
O esquema para o arquivoapplication.xml
não pôde ser encontrado no http://java.sun.com/xml/ns/javaee/application_6.xsd.Nota
Lembre-se de que a configuração do elemento<initialize-in-order>
paratrue
reduz a velocidade da implantação. É preferível definir as dependências de maneira apropriada usando injeções de dependência ou referências de recurso, uma vez que isto permite o contêiner maior flexibilidade na implantações ideais. - jboss-ejb3.xml
- O descritor da implantação
jboss-ejb3.xml
substitui o descritor da implantaçãojboss.xml
para substituição e adição à recursos fornecidos pelo Java Enterprise Edition (EE - Edição do Java Enterprise) definidos no descritor da implantaçãoejb-jar.xml
. O novo arquivo é incompatível com ojboss.xml
e ojboss.xml
é agora ignorado nas implantações. - login-config.xml
- O arquivo
login-config.xml
não é mais usado para a configuração de segurança. A segurança é agora configurada no elemento<security-domain>
no arquivo de configuração do servidor. Para um servidor autônomo, este é o arquivostandalone/configuration/standalone.xml
. Caso esteja executando o seu servidor num managed domain, esse é o arquivodomain/configuration/domain.xml
.
3.1.3.2. jboss-deployment-structure.xml
jboss-deployment-structure.xml
é um novo descritor de implantação opcional para o JBoss EAP 6. Este descritor de implantação fornece controle sobre o carregamento da classe na implantação.
EAP_HOME/docs/schema/jboss-deployment-structure-1_2.xsd
3.1.3.3. Recursos de Pacote para o Novo Sistema de Carregamento de Classe Modular
Nas versões anteriores do JBoss EAP, todos os recursos dentro do diretório WEB-INF/
foram adicionados ao caminho de classe WAR. No JBoss EAP 6, os artefatos do aplicativo da web são apenas carregados a partir dos diretórios WEB-INF/classes
e WEB-INF/lib
. A falha dos artefatos do aplicativo do pacote nas localizações especificadas pode resultar no ClassNotFoundException
, NoClassDefError
, ou outros erros do período de execução.
- Modificação do Empacotamento de Recurso
- Para disponibilizar os recursos apenas para o aplicativo, os arquivos de propriedades, JARs e outros artefatos com WAR devem ser empacotados, movendo-os ao diretório
WEB-INF/classes/
ouWEB-INF/lib/
. Essa abordagem está descrita em maiores detalhes na: Seção 3.1.3.4, “Alteração da Localização das Propriedades ResourceBundle” - Criação de um Módulo Personalizado
- Caso deseje disponibilizar recursos personalizados a todos os aplicativos executando no servidor do JBoss EAP 6, crie um modelo personalizado. Esta abordagem está descrita em maiores detalhes na: Seção 3.1.3.5, “Criação de um Módulo Personalizado”
3.1.3.4. Alteração da Localização das Propriedades ResourceBundle
Nas versões anteriores do JBoss EAP, o diretório EAP_HOME/server/SERVER_NAME/conf/
estava no classpath e disponível ao aplicativo. Para disponibilizar as propriedades ao caminho da classe do aplicativo no JBoss EAP 6, elas devem ser empacotadas com o seu aplicativo.
Procedimento 3.2. Altere a Localização das Propriedades ResourceBundle
- Caso esteja implantando um arquivo WAR, essas propriedades devem ser empacotadas na pasta
WEB-INF/classes/
do WAR. - Caso deseje disponibilizar essas propriedades a todos os componentes num EAR, elas devem ser empacotadas à raiz do JAR na pasta
lib/
do EAR.
3.1.3.5. Criação de um Módulo Personalizado
Procedimento 3.3. Criação de um Módulo Personalizado
- Crie e preencha a estrutura do diretório
module/
.- Crie uma estrutura de diretório sob o diretório
EAP_HOME/module
para conter os arquivos e JARs. Por exemplo:$ cd EAP_HOME/modules/
$ mkdir -p myorg-conf/main/properties
- Mova os arquivos de propriedades ao diretório
EAP_HOME/modules/myorg-conf/main/properties/
criado na etapa anterior. - Crie um arquivo
module.xml
no diretórioEAP_HOME/modules/myorg-conf/main/
contendo o seguinte XML:<module xmlns="urn:jboss:module:1.1" name="myorg-conf"> <resources> <resource-root path="properties"/> </resources> </module>
- Modifique o subsistema
ee
no arquivo de configuração do servidor. Você pode usar o JBoss CLI ou pode editar manualmente o arquivo.- Siga as seguintes etapas para modificar o arquivo de configuração do servidor usando o JBoss CLI.
- Inicie o servidor e conecte-se ao Management CLI.
- Insira a seguinte linha de comando para o Linux:
$ EAP_HOME/bin/jboss-cli.sh --connect
- Insira a seguinte linha de comando para o Windows:
C:\>EAP_HOME\bin\jboss-cli.bat --connect
Você deverá observar a seguinte resposta:Conectado ao controlador autônomo no localhost:9999
- Digite o seguinte na linha de comando para criar o elemento
myorg-conf
<global-modules> no subsistemaee
:/subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])
Você deverá ver o seguinte resultado:{"outcome" => "success"}
- Siga essas etapas caso prefira editar manualmente o arquivo da configuração do servidor.
- Interrompa o servidor e abra o arquivo de configuração do servidor num editor de texto. Caso esteja executando um servidor autônomo, o arquivo será o
EAP_HOME/standalone/configuration/standalone.xml
ou caso esteja executando um managed domain, o arquivo será oEAP_HOME/domain/configuration/domain.xml
. - Encontre o subsistema
ee
e adicione o módulo global paramyorg-conf
. Segue abaixo uma amostra do elemento do subsistemaee
modificado para inclusão do elementomyorg-conf
:<subsystem xmlns="urn:jboss:domain:ee:1.0" > <global-modules> <module name="myorg-conf" slot="main" /> </global-modules> </subsystem>
- Assumindo que você copiou um arquivo nomeado
my.properties
à localização de módulo correta, você poderá agora carregar os arquivos de propriedades usando o código similar ao seguinte:Thread.currentThread().getContextClassLoader().getResource("my.properties");
3.1.4. Alterações do Registro em Log
3.1.4.1. Modificação das Dependências de Registro em Log
O JBoss LogManager suporta front ends para todos os frameworks de registro em log, de forma que é possível manter seu código de registro de log atual ou mover à nova infraestrutura de registro de log do JBoss. Independente de sua decisão, devido às alterações de carregamento de classe modular, é provável a necessidade de modificação de seu aplicativo para adição das dependências requeridas.
Procedimento 3.4. Atualização do código de registro de log do aplicativo
3.1.4.2. Atualização do Código do Aplicativo para Frameworks de Registro de Log de Terceiros
No JBoss EAP 6, as dependências de registro em log para frameworks de terceiros comuns como o Apache Commons Logging, Apache log4j, SLF4J e Java Logging são adicionados por default. Normalmente, prefere-se o uso de um framework de logon fornecido pelo contêiner do JBoss EAP. No entanto, caso queira especificar a funcionalidade fornecida por um framework de terceiros, o módulo do JBoss EAP correspondente deve ser excluído de sua implantação. Perceba que embora sua implementação use um framework de logon de terceiros, os logs do servidor continuam a usar a configuração do subsistema de logon do JBoss EAP.
org.apache.log4j
do JBoss EAP 6 de sua implantação. O primeiro procedimento funciona em qualquer lançamento do JBoss EAP 6. O segundo procedimento é válido apenas ao JBoss EAP 6.3 ou versões mais avançadas.
Procedimento 3.5. Configuração do JBoss EAP 6 para uso de um arquivo log4j.properties ou log4j.xml
Nota
- Criação de um
jboss-deployment-structure.xml
com o seguinte conteúdo:<jboss-deployment-structure> <deployment> <!-- Exclusions allow you to prevent the server from automatically adding some dependencies --> <exclusions> <module name="org.apache.log4j" /> </exclusions> </deployment> </jboss-deployment-structure>
- Posicione o arquivo
jboss-deployment-structure.xml
, tanto em seu diretórioMETA-INF/
ou no diretórioWEB-INF/
, caso esteja implantando um WAR. Do contrário, posicione-o no diretórioMETA-INF/
caso esteja implantando um EAR. Caso a sua implantação incluir implantações filho dependente, o módulo deve ser também excluído para cada subimplantação. - Adicione o arquivo
log4j.properties
oulog4j.xml
no diretóriolib/
de seu EAR ou no diretórioWEB-INF/classes/
de sua implantação WAR. Caso deseje posicionar o arquivo no diretóriolib/
de seu WAR, o caminho<resource-root>
deve ser especificado no arquivojboss-deployment-structure.xml
.<jboss-deployment-structure> <deployment> <!-- Exclusions allow you to prevent the server from automatically adding some dependencies --> <exclusions> <module name="org.apache.log4j" /> </exclusions> <resources> <resource-root path="lib" /> </resources> </deployment> </jboss-deployment-structure>
- Inicie o servidor do JBoss EAP 6 com o seguinte argumento para evitar que um
ClassCastException
apareça no console no momento de implantação de seu aplicativo:-Dorg.jboss.as.logging.per-deployment=false
- Implante seu aplicativo.
Procedimento 3.6. Configuração das Dependências de Logon para o JBoss EAP 6.3 ou versões mais recentes
add-logging-api-dependencies
para exclusão das dependências do framework de logon de terceiros pode ser efetuado. As seguintes etapas demonstram como modificar este atributo de logon num servidor autônomo do JBoss EAP.
- Inicie o servidor do JBoss EAP 6 com o seguinte argumento para evitar que um
ClassCastException
apareça no console no momento de implantação de seu aplicativo:-Dorg.jboss.as.logging.per-deployment=false
- Abra um terminal e conecte-se ao Management CLI.
- Insira a seguinte linha de comando para o Linux:
$ EAP_HOME/bin/jboss-cli.sh --connect
- Insira a seguinte linha de comando para o Windows:
C:\>EAP_HOME\bin\jboss-cli.bat --connect
- Modifique o atributo
add-logging-api-dependencies
no subsistema de logon.Este atributo controla se o contêiner adiciona implicitamente as dependências API de logon as suas implantações.- Caso determinado para
true
, que é o default, todas as dependências API de logon implícitas serão adicionadas. - Caso determinado para
false
, as dependências não são adicionadas as suas implantações.
Este atributo deve ser determinado parafalse
usando o seguinte comando, com o objetivo de excluir as dependências do framework de logon de terceiros:/subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)
Este comando adiciona o elemento<add-logging-api-dependencies>
ao subsistemalogging
do arquivo de configuraçãostandalone.xml
.<subsystem xmlns="urn:jboss:domain:logging:1.4"> <add-logging-api-dependencies value="false"/> .... </subsystem>
- Implante seu aplicativo.
3.1.4.3. Modificação do Código para Uso do Novo Framework de Registro de Log do JBoss
Para usar o novo framework, altere suas importações e código conforme abaixo:
Procedimento 3.7. Modifique o Código e Dependências para Uso do JBoss logging Framework
Alteração de suas importações e código de registro em log
Segue abaixo uma amostra do código que usa o novo framework do JBoss Logging:import org.jboss.logging.Level; import org.jboss.logging.Logger; private static final Logger logger = Logger.getLogger(MyClass.class.toString()); if(logger.isTraceEnabled()) { logger.tracef("Starting...", subsystem); }
Adição de dependência de registro em log
O JAR contendo as classes do JBoss Logging está localizado no módulo nomeadoorg.jboss.logging
. O seu arquivoMANIFEST-MF
deve parecer com o seguinte:Manifest-Version: 1.0 Dependencies: org.jboss.logging
Por favor consulte a Seção 3.1.2.3, “Atualização das Dependências do Aplicativo devido às Alterações do Carregamento da Classe” e a Seção 4.2.1, “Depuração e Solução dos Problemas de Migração” para maiores informações sobre como encontrar a dependência do módulo.
3.1.5. Alterações do Empacotamento do Aplicativo
3.1.5.1. Modificação do Empacotamento dos EARS e WARs
Quando a migração de seu aplicativo for efetuada, será possível a necessidade de alteração da estrutura de empacotamento de seu EAR ou WAR devido à alteração do carregamento da classe modular. As dependências de módulo contém o carregamento em ordem específica:
- Dependências do sistema
- Dependências do Usuário
- Recursos Locais
- Dependências inter-implantadas
Procedimento 3.8. Modificação do empacotamento do arquivo
Empacotamento do WAR
O WAR é um módulo único e todas as classes no WAR são carregadas com o mesmo carregador de classe. Isto significa que as classes empacotadas no diretórioWEB-INF/lib/
são tratadas da mesma forma que as classes no diretórioWEB-INF/classes
.Empacotamento de um EAR
Um EAR consiste de módulos múltiplos. O diretórioEAR/lib/
é um módulo único e cada WAR ou subimplantação EJB jar no EAR é um módulo separado. As classes não possuem acesso às classes em outros módulos com o EAR, a não ser que as dependências tenham sido definidas. As subimplantações sempre possuem uma dependência automática no módulo pai que as fornecem acesso às classes no diretórioEAR/lib/
. No entanto, as subimplantações nem sempre possuem uma dependência automática para permitir que se acessassem entre si. Este comportamento é controlado pela configuração do elemento<ear-subdeployments-isolated>
na configuração do subsistemaee
, conforme abaixo:<subsystem xmlns="urn:jboss:domain:ee:1.0" > <ear-subdeployments-isolated>false</ear-subdeployments-isolated> </subsystem>
Por default, isto é configurado para falso, permitindo que as subimplantações vejam as classes pertencentes às demais subimplantações com o EAR.Refira-se ao capítulo nomeado no carregamento da classe ao capítulo nomeado Carregamento de Classe e Módulos no Guia de Desenvolvimento para o JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.
3.1.6. Alterações da Configuração do Adaptador de Recurso e Fonte de Dados
3.1.6.1. Atualização do Aplicativo devido às Alterações da Configuração
- Caso seu aplicativo use a fonte de dados, consulte a: Seção 3.1.6.2, “Atualização da Configuração da Fonte de Dados”.
- Caso o seu aplicativo use o JPA e empacote os Hibernate JARs, consulte a: Seção 3.1.6.4, “Configuração da Fonte de Dados para o Hibernate ou JPA” para opções de migração.
- Caso seu aplicativo use um adaptador de recurso, consulte a: Seção 3.1.6.5, “Atualização da Configuração do Adaptador de Recurso”.
- Revise a seguinte informação de como configurar as alterações para a segurança básica na: Seção 3.1.7.1, “Configuração das Alterações de Segurança do Aplicativo”.
3.1.6.2. Atualização da Configuração da Fonte de Dados
Nas versões anteriores do JBoss EAP, a configuração da fonte de dados JCA foi definida num arquivo com sufixo *-ds.xml
. Esse arquivo foi implantado no diretório deploy/
do servidor ou empacotado com o aplicativo. O driver JDBC foi copiado ao diretório server/lib/
ou empacotado no diretório WEB-INF/lib/
do aplicativo. Enquanto esse método de configuração de fonte de dados não é suportado para o desenvolvimento, ele não é recomendado para produção uma vez que ele não é suportado pelas ferramentas de gerenciamento e administrativa do JBoss.
domain/configuration/domain.xml
. Caso a instância do JBoss EAP estiver sendo executada como servidor autônomo, a fonte de dados é configurada no standalone/configuration/standalone.xml file
. As fontes de dados configuradas dessa maneira podem ser gerenciadas e controladas usando as interfaces de gerenciamento do JBoss, incluindo o Web Management Console e a interface da linha de comando (CLI - command line interface). Essas ferramentas facilitam o gerenciamento de implantações e configuram servidores múltiplos sendo executados no managed domain.
Um driver compatível com JDBC 4.0 pode ser instalado como implantação ou como módulo principal. Um driver que é compatível com o JDBC 4.0 contém um arquivo META-INF/services/java.sql.Driver
que especifica o nome da classe do driver. Um driver que não é compatível com o JDBC 4.0 requer etapas adicionais. Para maiores detalhes de como fazer um driver compatível com o JDBC 4.0 e como atualizar sua configuração de fonte de dados atual para uma gerenciável pelo Web Management Console and CLI, consulte a Seção 3.1.6.3, “Instalação e Configuração do JDBC Driver”.
Você pode usar a ferramenta IronJacamar para migrar a fonte de dados e as configurações do adaptador do recurso. Esta ferramenta converte os arquivos de configuração do estilo *-ds.xml
no formato esperado pelo JBoss EAP 6. Consute a Seção 4.1.6, “Uso da Ferramenta IronJacamar para Migração da Fonte de Dados e Configurações do Adaptador de Recurso” para maiores informações.
3.1.6.3. Instalação e Configuração do JDBC Driver
O JDBC driver pode ser instalado no contêiner em uma das duas seguintes maneiras:
- como implantação;
- como módulo core.
domain/configuration/domain.xml
. Caso a instância do JBoss EAP 6 estiver sendo executada como um servidor autônomo, a fonte de dados é configurada no arquivo standalone/configuration/standalone.xml
. A informação da referência do esquema, que é a mesma em ambos os modos, pode ser encontrada no diretório doc/
de instalação do JBoss EAP 6. Para propósitos desta discussão, assuma que o servidor está sendo executado como servidor autônomo e a fonte de dados está configurada no arquivo standalone.xml
.
Procedimento 3.9. Instalação e Configuração do JDBC Driver
Instale o JDBC Driver.
Instale o JDBC Driver como uma implantação.
Esta é a maneira recomendada de instalação do driver. Quando o JDBC driver for instalado como uma implantação, ele é implantado como um JAR regular. Caso a instância do JBoss EAP 6 estiver sendo executada como um servidor autônomo, copie o JDBC 4.0 compatível com o diretórioEAP_HOME/standalone/deployments/
. Para um managed domain, o Management Console ou Management CLI deve ser usado para implantar o JAR aos grupos do servidor.Segue abaixo uma amostra de um MySQL JDBC driver instalado como implantação ao servidor autônomo:$cp mysql-connector-java-5.1.15.jar
EAP_HOME/standalone/deployments/
Qualquer driver compatível com o JDBC 4.0 é automaticamente reconhecido e instalado no sistema pelo nome e versão. Um JAR compatível com o JDBC 4.0 contém um texto com arquivo nomeadoMETA-INF/services/java.sql.Driver
que especifica o(s) nome(s) da classe do driver. Caso o driver não for compatível com o JDBC 4.0, ele pode ser implantável em uma das seguintes maneiras:- Crie e adicione o arquivo
java.sql.Driver
ao JAR sob o caminhoMETA-INF/services/
. Esse arquivo deve conter o nome de classe do driver, por exemplo:com.mysql.jdbc.Driver
- Crie um arquivo
java.sql.Driver
no diretório de implementação. Para uma instância do JBoss EAP 6 executando como um servidor autônomo, o arquivo deve ser posicionado no:EAP_HOME/standalone/deployments/META-INF/services/java.sql.Driver
. Caso o servidor estiver num managed domain, o uso do Management Console ou do Managment CLI deve ser aplicado para implantar o arquivo.
Os aspectos positivos desta abordagem são:Os aspectos negativos desta abordagem são:- Este é o método mais simples uma vez que não há necessidade de definir um módulo.
- Quando o servidor estiver executando num managed domain, as implantações que usam esta abordagem são propagadas automaticamente a todos os servidores no domain. Isto significa que o administrador não precisa distribuir o driver JAR manualmente.
- Caso o JDBC driver consistir de mais de um JAR, por exemplo o driver JAR mais o JAR da licença de dependência JAR ou JAR de localização, o driver não pode ser instalado como implantação. O JDBC deve ser instalado como um módulo core.
- Caso o driver não for compatível com o JDBC 4.0, um arquivo deve ser criado contendo o(s) nome(s) da classe do driver e deve ser importado num JAR ou sobreposto no diretório
deployments/
.
Instale o JDBC Driver como um módulo core.
Para instalar um JDBC driver como um módulo core, uma estrutura do caminho do arquivo sob o diretórioEAP_HOME/modules/
deve ser criada. Esta estrutura contém o JDBC driver JAR, qualquer licença do fornecedor adicional ou JARs de localização e um arquivomodule.xml
para definição do módulo.Instale o MySQL JDBC Driver como módulo core
- Crie uma estrutura de diretório
EAP_HOME/modules/com/mysql/main/
- No subdiretório
main/
, crie um arquivomodule.xml
contendo a seguinte definição do módulo para o MySQL JDBC driver:<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.0" name="com.mysql"> <resources> <resource-root path="mysql-connector-java-5.1.15.jar"/> </resources> <dependencies> <module name="javax.api"/> </dependencies> </module>
O nome do módulo, "com.mysql", coincide com a estrutura do diretório para esse módulo. O elemento<dependencies>
é usado para especificar as dependências do módulo em outros módulos. Neste caso, como é o caso em todas as fontes de dados JDBC, isto é dependente do Java JDBC APIs que é definido em outro módulo nomeadojavax.api
. Este módulo está localizado sob o diretóriomodules/system/layers/base/javax/api/main/
.Nota
Certifique-se de que NÃO possui espaço no início do arquivomodule.xml
ou um erro "Novas dependências ausentes/não satisfatórias" para este driver será obtido. - Copie o MySQL JDBC driver JAR ao diretório
EAP_HOME/modules/com/mysql/main/
:$ cp mysql-connector-java-5.1.15.jar
EAP_HOME/modules/com/mysql/main/
Instale o IBM DB2 JDBC driver e JAR de licença como um módulo core.
Esta amostra é fornecida para apenas demonstrar como implantar drivers que requerem JARs além do JDBC Driver JAR.- Crie a estrutura do diretório
EAP_HOME/modules/com/ibm/db2/main/
. - No subdiretório
main/
crie um arquivomodule.xml
contendo a seguinte definição do módulo para o IBM DB2 JDBC driver e licença:<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.1" name="com.ibm.db2"> <resources> <resource-root path="db2jcc.jar"/> <resource-root path="db2jcc_license_cisuz.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
Nota
Certifique-se de que NÃO possui espaço no início do arquivomodule.xml
ou um erro "Novas dependências ausentes/não satisfatórias" para este driver será obtido. - Copie o JDBC driver e a licença JAR ao diretório
EAP_HOME/modules/com/ibm/db2/main/
.$ cp db2jcc.jar
EAP_HOME/modules/com/ibm/db2/main/
$ cp db2jcc_license_cisuz.jarEAP_HOME/modules/com/ibm/db2/main/
Os aspectos positivos desta abordagem são:Os aspectos negativos desta abordagem são:- Esta é a única abordagem que funciona quando o JDBC driver consiste de mais de um JAR.
- Com esta abordagem, os drivers que não são compatíveis com o JDBC 4.0 podem ser instalados sem modificar o driver JAR ou criando uma sobreposição de arquivo.
- É mais difícil configurar um módulo.
- O módulo deve ser manualmente copiado para cada servidor executando num managed domain.
Configure a fonte de dados.
Adicione o driver do banco de dados.
Adicione o elemento<driver>
ao elemento<drivers>
de mesmo arquivo. Isto contém algumas das informações que foram definidas anteriormente no arquivo*-ds.xml
.Primeiro determine se o driver JAR é compatível com o JDBC 4.0. Um JAR que é compatível com o JDBC 4.0 contém um arquivoMETA-INF/services/java.sql.Driver
que especifica o nome de classe do driver. O servidor usa este arquivo para encontrar o nome da(s) classe(s) de driver no JAR. Um driver que é compatível com o JDBC 4.0 não requer um elemento<driver-class>
, uma vez que ele já está especificado no JAR. Esta é uma amostra do elemento do driver para um JDBC 4.0 compatível com o driver MySQL:<driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"/>
Um driver que não seja compatível com o JDBC 4.0 requer um atributo<driver-class>
para identificar a classe do driver desde que não haja um arquivoMETA-INF/services/java.sql.Driver
que especifique o nome da classe do driver. Segue abaixo uma amostra do elemento driver para o driver não compatível com o JDBC 4.0:<driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"> <driver-class>com.mysql.jdbc.Driver</driver-class></driver>
Crie a fonte de dados.
Crie um elemento<datasource>
na seção<datasources>
do arquivostandalone.xml
. Este arquivo contém bastante informações da fonte de dados anteriormente definida no arquivo*-ds.xml
.Importante
O servidor deve ser interrompido antes de editar o arquivo de configuração do servidor para que sua alteração seja efetivada no reinício do servidor.Segue abaixo uma amostra de um elemento de fonte de dados MySQL no arquivostandalone.xml
:<datasource jndi-name="java:/YourDatasourceName" pool-name="YourDatasourceName"> <connection-url>jdbc:mysql://localhost:3306/YourApplicationURL</connection-url> <driver>mysql-connector-java-5.1.15.jar</driver> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation> <pool> <min-pool-size>100</min-pool-size> <max-pool-size>200</max-pool-size> </pool> <security> <user-name>USERID</user-name> <password>PASSWORD</password> </security> <statement> <prepared-statement-cache-size>100</prepared-statement-cache-size> <share-prepared-statements/> </statement> </datasource>
Atualize as referências JNDI no código do aplicativo.
Os nomes de pesquisa JNDI antigos no código fonte do aplicativo devem ser substituídos para uso dos nomes da fonte de dados padronizados do JNDI definidos anteriormente. Consulte a Seção 3.1.8.4, “Modificação do Aplicativo para Seguir as Novas Regras do JNDI Namespace” para maiores informações.Quaisquer anotações@Resource
existentes devem ser também substituídas, das quais acessam a fonte de dados para uso do novo nome JNDI. Por exemplo:@Resource(name = "java:/YourDatasourceName").
3.1.6.4. Configuração da Fonte de Dados para o Hibernate ou JPA
Procedimento 3.10. Remoção do pacote Hibernate
- Remova o Hibernate JARs de suas pastas da biblioteca do aplicativo.
- Remova ou comente o elemento
<hibernate.transaction.manager_lookup_class>
em seu arquivopersistence.xml
, uma vez que este elemento não é necessário.
3.1.6.5. Atualização da Configuração do Adaptador de Recurso
Nas versões anteriores do servidor do aplicativo, a configuração do adaptador do recurso era definida num arquivo com um sufixo *-ds.xml
. No JBoss EAP 6, um adaptador de recurso é configurado num arquivo de configuração do servidor. Caso esteja executando num managed domain, o arquivo de configuração é o arquivo EAP_HOME/domain/configuration/domain.xml
. Caso esteja executando num servidor autônomo, configure o adaptador de recurso no arquivo EAP_HOME/standalone/configuration/standalone.xml
. A informação da referência do esquema, que é a mesma para ambos os módulos, pode ser encontrada sob Esquemas no website do IronJacamar: http://www.ironjacamar.org/documentation.html.
Importante
A informação do descritor do adaptador de recurso está definida no elemento do seguinte subsistema no arquivo de configuração do servidor:
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1"/>Algumas das informações definidas anteriormente no arquivo
*-ds.xml
do adaptador de recurso poderão ser usadas.
<resource-adapters> <resource-adapter> <archive>multiple-full.rar</archive> <config-property name="Name">ResourceAdapterValue</config-property> <transaction-support>NoTransaction</transaction-support> <connection-definitions> <connection-definition class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleManagedConnectionFactory1" enabled="true" jndi-name="java:/eis/MultipleConnectionFactory1" pool-name="MultipleConnectionFactory1"> <config-property name="Name">MultipleConnectionFactory1Value</config-property> </connection-definition> <connection-definition class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleManagedConnectionFactory2" enabled="true" jndi-name="java:/eis/MultipleConnectionFactory2" pool-name="MultipleConnectionFactory2"> <config-property name="Name">MultipleConnectionFactory2Value</config-property> </connection-definition> </connection-definitions> <admin-objects> <admin-object class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleAdminObject1Impl" jndi-name="java:/eis/MultipleAdminObject1"> <config-property name="Name">MultipleAdminObject1Value</config-property> </admin-object> <admin-object class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleAdminObject2Impl" jndi-name="java:/eis/MultipleAdminObject2"> <config-property name="Name">MultipleAdminObject2Value</config-property> </admin-object> </admin-objects> </resource-adapter> </resource-adapters>
3.1.7. Alterações de Segurança
3.1.7.1. Configuração das Alterações de Segurança do Aplicativo
Nas versões anteriores do JBoss EAP, os arquivos de propriedades posicionados no diretório EAP_HOME/server/SERVER_NAME/conf/
estavam no classpath e poderiam ser facilmente encontrados pelo UsersRolesLoginModule
. No JBoss EAP 6, a estrutura do diretório foi alterada. Os arquivos da propriedade devem ser empacotados com aplicativo para disponibilizá-los no classpath.
Importante
security-domains
para o standalone/configuration/standalone.xml
ou o arquivo de configuração do servidor domain/configuration/domain.xml
:
<security-domain name="example"> <authentication> <login-module code="UsersRoles" flag="required"> <module-option name="usersProperties" value="${jboss.server.config.dir}/example-users.properties"/> <module-option name="rolesProperties" value="${jboss.server.config.dir}/example-roles.properties"/> </login-module> </authentication> </security-domain>
${jboss.server.config.dir}
refere-se ao diretório EAP_HOME/standalone/configuration/
. Caso a instância estiver executando num managed domain, o ${jboss.server.config.dir}
refere-se ao diretório EAP_HOME/domain/configuration/
.
Os security domains não usam mais o prefixo java:/jaas/
em seus nomes no JBoss EAP 6.
- Esse prefixo das configurações do security domain para os aplicativos da Web no
jboss-web.xml
deve ser removido. - Esse prefixo das configurações do security domain para os aplicativos Enterprise no
jboss-web.xml
deve ser removido. Esse arquivo foi substituído pelojboss.xml
no JBoss EAP 6.
3.1.7.2. Atualização dos Aplicativos que usam o PicketLink STS e Web Services
Caso seu aplicativo do JBoss EAP 6.1 use o PicketLink STS e serviços da Web, pode ser necessária a realização de alterações quando ocorrer a migração para o JBoss EAP 6.2 ou versões mais avançadas. Uma correção realizada no JBoss EAP, para o endereço CVE-2013-2133, reforça as checagens da autorização pelo contêiner antes da execução de quaisquer manuseadores JAXWS anexados aos pontos de extremidade WS baseado no EJB3. Consequentemente, algumas das funcionalidades do PicketLink podem ser afetadas uma vez que o PicketLink SAML2Handler
estabiliza uma segurança principal que será necessária mais tarde para uso. O NullPointerException
talvez seja visualizado no log do servidor uma vez que o principal é NULL
quando o HandlerAuthInterceptor
acessa o SAML2Handler
. Esta verificação de segurança pode ser desabilitada para correção deste problema.
Procedimento 3.11. Desabilitação das Verificações de Autorização Adicional
- As verificações de autorização adicional podem ser desabilitadas e continuarem usando as implantações PicktLink existentes, pelo uso de um dos seguintes métodos.
Determinação da Propriedade em todo o Sistema
As verificações de autorização adicional podem ser desabilitadas ao nível do servidor pela determinação do valor do sistema de propriedadeorg.jboss.ws.cxf.disableHandlerAuthChecks
paratrue
. Este método afeta qualquer implantação realizada ao servidor do aplicativo.Consulte o tópico nomeado Configuração das Propriedades de Sistema usando o Management CLI no Guia de Configuração e Administração do JBoss EAP para maiores informações sobre como determinar uma propriedade de sistema.Criação de uma Propriedade no Arquivo do Descritor do Web Services de Implantação
As verificações de autorização no nível de implantação podem ser desabilitadas pela configuração do valor da propriedadeorg.jboss.ws.cxf.disableHandlerAuthChecks
paratrue
no arquivojboss-webservices.xml
.- Crie um arquivo
jboss-webservices.xml
no diretórioMETA-INF/
da implantação pela qual deseja desabilitar as verificações da autorização. - Adicione o seguinte conteúdo:
<?xml version="1.1" encoding="UTF-8"?> <webservices xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.2" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee"> <property> <name>org.jboss.ws.cxf.disableHandlerAuthChecks</name> <value>true</value> </property> </webservices>
Nota
org.jboss.ws.cxf.disableHandlerAuthChecks
renderiza um sistema vulnerável ao CVE-2013-2133. Caso o aplicativo esperar por restrições de segurança declaradas nos métodos EJB a serem aplicados e não aplicá-los independentemente ao manuseador JAX-WS, a propriedade não deve ser habilitada. A propriedade deve ser apenas usada para propósitos de compatibilidade inversa, quando necessário, para evitar a interrupção do aplicativo.
3.1.8. Alterações JNDI
3.1.8.1. Atualização dos Nomes JNDI Namespace do Aplicativo
O EJB 3.1 introduziu um JNDI namespace global padronizado e uma série de namespaces relacionados que mapeiam vários escopos do aplicativo Java EE. Os nomes do EJB Portátil é apenas limitado a três deles: java:global
, java:module
e java:app
. Os aplicativos com os EJBs que usam o JNDI devem ser alterados para seguirem a nova convenção padronizada do JNDI namespace.
Procedimento 3.12. Modificação das pesquisas JNDI
- Leia mais a respeito deste assunto na Seção 3.1.8.2, “Nomes do EJB JNDI Portátil ”
As amostras de espaços de nome JNDI dos lançamentos anteriores e como eles são especificados no JBoss EAP podem ser encontradas na: Seção 3.1.8.5, “Amostra do JNDI Namespaces nos Lançamentos Anteriores e como são especificados no JBoss EAP 6”
3.1.8.2. Nomes do EJB JNDI Portátil
A especificação do Java EE 6 define quatro namespaces lógicos, cada um com o seu próprio escopo. No entanto, os nomes do EJB portátil apenas obtém o limite de três deles. A seguinte tabela detalha quando e como usar cada namespace.
Tabela 3.1. Namespaces JNDI Portáveis
JNDI Namespace | Descrição |
---|---|
java:global |
Os nomes neste namespace são compartilhados em todos os aplicativos implantados numa instância do servidor do aplicativo. Use nomes neste namespace para encontrar os arquivos EJBs externos no mesmo servidor.
Segue abaixo uma amostra do java:global namespace:
java:global/jboss-seam-booking/jboss-seam-booking-jar/HotelBookingAction
|
java:module |
Os nomes neste namespace são compartilhados por todos os componentes num módulo, por exemplo: todos os enterprise beans num módulo EJB único ou todos os componentes num módulo da web.
Segue abaixo uma amostra do java:module namespace:
java:module/HotelBookingAction!org.jboss.seam.example.booking.HotelBooking
|
java:app |
Os nomes neste namespace são compartilhados por todos os componentes num aplicativo único. Por exemplo, um WAR e um arquivo EJB jar no mesmo arquivo EAR teriam acesso aos recursos no java:app namespace.
Segue abaixo uma amostra do java:app namespace:
java:app/jboss-seam-booking-jar/HotelBookingAction
|
3.1.8.3. Revisão das Regras JNDI Namespace
O JBoss EAP 6 aprimorou os nomes do JNDI namespace, não apenas para fornecer regras consistentes e premeditadas para cada nome limitado no servidor do aplicativo, mas também para prevenir problemas futuros de compatibilidade. Isto significa que você poderá ter problemas com os namespaces atuais no seu aplicativo, caso eles não seguirem as novas regras.
- Os nomes relativos não qualificados como o
DefaultDS
oujdbc/DefaultDS
devem ser relativamente qualificados para ojava:comp/env
,java:module/env
oujava:jboss/env
, dependendo do contexto. - Os nomes
absolute
não qualificados como/jdbc/DefaultDS
devem ser relativamente qualificados a um nomejava:jboss/root
. - Os nomes
absolute
qualificados como ojava:/jdbc/DefaultDS
devem ser qualificados da mesma forma que os nomesabsolute
não qualificados acima. - O espaço do nome
java:jboss
especial é compartilhado por toda a instância do servidor AS. - Qualquer nome
relative
com o prefixojava:
deve estar em um dos cinco espaços do nome:comp
,module
,app
,global
oujboss
proprietário. Qualquer nome começando comjava:xxx
onde xxx não coincida com nenhum dos cinco acima, resultaria num erro de nome inválido.
3.1.8.4. Modificação do Aplicativo para Seguir as Novas Regras do JNDI Namespace
- Segue abaixo uma amostra da pesquisa JNDI no JBoss EAP 5.1. Este código é normalmente encontrado num método de inicialização.
private ProductManager productManager; try { context = new InitialContext(); productManager = (ProductManager) context.lookup("OrderManagerApp/ProductManagerBean/local"); } catch(Exception lookupError) { throw new ServletException("Unable to find the ProductManager bean", lookupError); }
Note que o nome de pesquisa éOrderManagerApp/ProductManagerBean/local
. - A seguinte amostra relata como a mesma busca poderia ser codificada no JBoss EAP 6 usando a injeção de dependência.
@EJB(lookup="java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager") private ProductManager productManager;
Os valores de pesquisa são definidos como variáveis do associado e usam o novo nomejava:app
JNDI namespacejava:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager
. - Caso sua preferência não seja o uso da injeção de dependência, a criação do novo InitialContect pode continuar conforme acima e a modificação da busca para uso do novo nome JNDI namespace pode ser realizada.
private ProductManager productManager; try { context = new InitialContext(); productManager = (ProductManager) context.lookup("java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager"); } catch(Exception lookupError) { throw new ServletException("Unable to find the ProductManager bean", lookupError); }
3.1.8.5. Amostra do JNDI Namespaces nos Lançamentos Anteriores e como são especificados no JBoss EAP 6
Tabela 3.2. Tabela de Mapeamento do JNDI Namespace
Namespace no JBoss EAP 5.x | Namespace no JBoss EAP 6 | Comentários adicionais |
---|---|---|
OrderManagerApp/ProductManagerBean/local | java:module/ProductManagerBean!services.ejb.ProductManager | O Java EE 6 binding default. Possui escopo para o módulo atual e apenas acessível com o mesmo módulo. |
OrderManagerApp/ProductManagerBean/local | java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager | O Java EE 6 binding default. Possui escopo para o aplicativo atual e apenas acessível com o mesmo aplicativo. |
OrderManagerApp/ProductManagerBean/local | java:global/OrderManagerApp/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager | O binding default do Java EE 6. Possui escopo para o servidor do aplicativo e acessível globalmente. |
java:comp/UserTransaction | java:comp/UserTransaction | O namespace possui escopo ao componente atual. Não é acessível para threads que não estão no Java EE 6, por exemplo: os threads criados diretamente pelo seu aplicativo. |
java:comp/UserTransaction | java:jboss/UserTransaction | Acessível globalmente. Use isto caso o java:comp/UserTransaction não esteja disponível. |
java:/TransactionManager | java:jboss/TransactionManager | |
java:/TransactionSynchronizationRegistry | java:jboss/TransactionSynchronizationRegistry |
3.2. Alterações Dependentes de seus Componentes e Arquitetura do Aplicativo
3.2.1. Revisão das Alterações dependentes de seus Componentes e Arquitetura do Aplicativo
- Hibernate e JPA
- O seu aplicativo precisará de algumas modificações, caso use o Hibernate ou JPA. Consulte a Seção 3.2.2.1, “Atualização dos Aplicativos que usam Hibernate e/ou JPA” para maiores informações.
- REST
- Caso seu aplicativo usar JAX-RS, você deve estar ciente de que o JBoss EAP 6 configura automaticamente o RESTEasy, de forma de que você não precisa mais configurá-lo automaticamente. Consulte a Seção 3.2.5.1, “Configuração das Alterações JAX-RS e RESTEasy” para maiores informações.
- LDAP
- O realm de segurança LDAP é configurado de forma diferente no JBoss EAP 6. Caso o seu aplicativo usar o LDAP, refira-se ao seguinte tópico para maiores informações na Seção 3.2.6.1, “Configuração das Alterações LDAP Security Realm”.
- Messaging
- O JBoss Messaging não está mais incluído no JBoss EAP 6. Caso o seu aplicativo usar o JBoss Messaging como provedor messaging, você precisará substituir o código do JBoss Messaging como o HornetQ. A seguinte Seção 3.2.7.4, “Migração de seu Aplicativo para uso do HornetQ como um Provedor JMS” descreve o que você precisa realizar.
- Clustering
- A maneira que você habilita o clustering foi alterada no JBoss EAP 6. Consulte a Seção 3.2.8.1, “Realize Alterações ao seu Aplicativo para o Clustering” para maiores detalhes.
- Implantação de Estilo de Serviço
- Embora o JBoss EAP 6 não use mais os descritores de estilo de serviço, o contêiner suporta essas implantações de estilo de serviço sem alterações onde possível. Consulte a Seção 3.2.9.1, “Atualização dos Aplicativos que usam as Implantações de Estilo de Serviço” para maiores informações.
- Invocação remota
- Caso o seu aplicativo realizar invocações remota, você pode continuar usando o JNDI para pesquisar um proxy para o seu bean e invocar aquele proxy retornado. Consulte a Seção 3.2.10.1, “Migração dos Aplicativos Implantados do JBoss EAP 5 que realiza Invocações Remotas ao JBoss EAP 6” para maiores informações sobre as alterações dos namespaces e a sintaxe requerida.
- Seam 2.2
- Caso o seu aplicativo usar o Seam 2.2, refira-se à seguinte Seção 3.2.13.1, “Migração dos Arquivos Seam 2.2 para o JBoss EAP 6” para melhor entendimento das alterações necessárias que você precisa realizar.
- Spring
- Consulte a Seção 3.2.14.1, “Aplicativos Spring de Migração” caso seu aplicativo usar o Spring.
- Outras alterações que podem afetar sua migração
- Para alterações adicionais do JBoss EAP 6 que podem impactar o seu aplicativo, consulte a Seção 3.2.15.1, “Outras alterações que podem afetar sua Migração”.
3.2.2. Alterações JPA e Hibernate
3.2.2.1. Atualização dos Aplicativos que usam Hibernate e/ou JPA
Caso seu aplicativo usar Hibernate ou JPA, leia as seguintes seções e realize quaisquer alterações necessárias para migrar ao JBoss EAP 6.
3.2.2.2. Configuração das Alterações para Aplicativos que usam o Hibernate e o JPA
Caso o seu aplicativo contenha um arquivo persistence.xml
ou um código usando anotações @PersistenceContext
ou @PersistenceUnit
, o JBoss EAP 6 detectará isto durante a implantação e assumirá que o aplicativo está usando o JPA. O Hibernate 4 é implicitamente adicionado, além de algumas outras dependências ao seu classpath do aplicativo.
ClassNotFoundExceptions
seja visualizado quando implantando seu aplicativo, pode ser possível resolvê-las usando uma das abordagens seguintes.
Importante
Procedimento 3.13. Configuração do Aplicativo
Copie o Hibernate 3 JARs requerido para sua biblioteca do aplicativo.
Você pode estar apto a resolver o problema copiando o Hibernate 3 JARs específico que contém classes ausentes no diretóriolib/
do aplicativo ou adicionando-as ao classpath usando algum outro método. Em alguns casos, isto pode resultar noClassCastExceptions
ou outros problemas de carregamento de classe devido ao uso misturado das versões Hibernate. Caso isto aconteça, você precisará usar a próxima abordagem.Instrução do servidor para uso apenas das bibliotecas HIbernate 3.
O JBoss EAP 6 permite você empacotar os jars do provedor de persistência Hibernate 3.5 (ou superior) com o aplicativo. Para direcionar o servidor para uso apenas das bibliotecas Hibernate 3 e excluir as bibliotecas do Hibernate 4, você precisa configurar ojboss.as.jpa.providerModule
parahibernate3-bundled
nopersistence.xml
, conforme abaixo:<?xml version="1.0" encoding="UTF-8"?> <persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0"> <persistence-unit name="plannerdatasource_pu"> <description>Hibernate 3 Persistence Unit.</description> <jta-data-source>java:jboss/datasources/PlannerDS</jta-data-source> <properties> <property name="hibernate.show_sql" value="false" /> <property name="jboss.as.jpa.providerModule" value="hibernate3-bundled" /> </properties> </persistence-unit> </persistence>
O implantador Java Persistence API (JPA) não irá detectar a presença de um provedor de persistência no aplicativo e uso das bibliotecas Hibernate 3. Conslute a Seção 3.2.2.3, “Propriedades da Unidade de Persistência” para maiores informações sobre as propriedades de persistência JPA.Desativação do cache de segundo nível
O cache de segundo nível para o Hibernate 3 não exibe o mesmo comportamento com o JBoss EAP 6 assim como fazia nas versões anteriores. Caso você esteja usando o cache de segundo nível com o seu aplicativo, você deve desativá-lo até atualizá-lo para o Hibernate 4. Para desativar o cache de segundo nível, configure o<hibernate.cache.use_second_level_cache>
parafalse
no arquivopersistence.xml
.
3.2.2.3. Propriedades da Unidade de Persistência
O JBoss EAP 6 configura automaticamente as seguintes propriedades da configuração Hibernate 4.x:
Tabela 3.3. Propriedades da Unidade de Persistência Hibernate
Nome da Propriedade | Valor Default | Propósito |
---|---|---|
hibernate.id.new_generator_mappings | verdadeiro |
Esta configuração é relevante caso esteja usando o
@GeneratedValue(AUTO) para gerar valores de chave de indexe único. Os novos aplicativos devem manter o valor default true . Os aplicativos existentes que usavam o Hibernate 3.3.x talvez tenham que alterar isto para false com o objetivo de continuar usando o objeto de sequência ou tabela baseada no gerador e manter a compatibilidade reversa. O aplicativo pode substituir esse valor no arquivo persistence.xml .
Maiores informações sobre este comportamento são fornecidas abaixo.
|
hibernate.transaction.jta.platform | Instância da Interface org.hibernate.service.jta.platform.spi.JtaPlatform |
Essa classe passa o gerenciador de transação, a transação do usuário e o registro de sincronização da transação no Hibernate.
|
hibernate.ejb.resource_scanner | Instância da Interface org.hibernate.ejb.packaging.Scanner |
Essa classe sabe como usar o indexe de anotação do JBoss EAP 6 para fornecer uma implantação mais rápida.
|
hibernate.transaction.manager_lookup_class |
Essa propriedade é removida caso encontrada no persistence.xml uma vez que isto pode entrar em conflito com o
hibernate.transaction.jta.platform
| |
hibernate.session_factory_name | QUALIFIED_PERSISTENCE_UNIT_NAME |
Isto é configurado para o nome do aplicativo + o nome da unidade da persistência. O aplicativo pode especificar um valor diferente, mas ele deve ser único por todas as implantações do aplicativo na instância do JBoss EAP 6.
|
hibernate.session_factory_name_is_jndi | falso |
Isto é configurado apenas se o aplicativo não tiver especificado um valor para o
hibernate.session_factory_name .
|
hibernate.ejb.entitymanager_factory_name | QUALIFIED_PERSISTENCE_UNIT_NAME |
Isto é configurado para o nome do aplicativo + o nome da unidade da persistência. O aplicativo pode especificar um valor diferente, mas ele deve ser único por todas as implantações do aplicativo na instância do JBoss EAP 6.
|
new_generator_mappings
esteja configurado para true
:
- O
@GeneratedValue(AUTO)
mapeia paraorg.hibernate.id.enhanced.SequenceStyleGenerator
. - O
@GeneratedValue(TABLE)
mapeia paraorg.hibernate.id.enhanced.TableGenerator
. - O
@GeneratedValue(SEQUENCE)
mapeia paraorg.hibernate.id.enhanced.SequenceStyleGenerator
.
new_generator_mappings
esteja configurado para false
:
- O
@GeneratedValue(AUTO)
mapeia para o Hibernate "native". - O
@GeneratedValue(TABLE)
mapeia para oorg.hibernate.id.MultipleHiLoPerTableGenerator
. - O
@GeneratedValue(SEQUENCE)
mapeia para o Hibernate "seqhilo".
As seguintes propriedades JPA são suportadas na definição de unidade de persistência no arquivo persistence.xml
:
Tabela 3.4. Propriedades da Unidade de Persistência JPA
Nome da Propriedade | Valor Default | Propósito |
---|---|---|
jboss.as.jpa.providerModule | org.hibernate |
O nome do fornecedor de persistência.
O valor deve ser
hibernate3-bundled caso os Hibernate 3 JARs estiverem no arquivo do aplicativo.
Caso o fornecedor de persistência for empacotado com o aplicativo, este valor deve ser
application .
|
jboss.as.jpa.adapterModule | org.jboss.as.jpa.hibernate:4 |
O nome das classes de integração que ajuda o JBoss EAP 6 a funcionar com o fornecedor de persistência.
Os valores válidos e corretos são:
|
3.2.2.4. Atualização de seu Aplicativo Hibernate 3 para uso do Hibernate 4
Quando você atualizar seu aplicativo para uso do Hibernate 4, algumas atualizações são gerais e válidas independente da versão Hibernate sendo usada no momento pelo aplicativo. Para as demais atualizações, a versão pela qual o aplicativo está usando deverá ser determinada.
Procedimento 3.14. Atualização do aplicativo para uso do Hibernate 4
- O comportamento default do gerador do string de incremento automático foi alterado no JBoss EAP 6. Consulte a Seção 3.2.2.5, “Mantenha o Comportamento Existente do Valor Gerado Automaticamente da Identidade Hibernate” para maiores informações.
- Determine a versão do Hibernate sendo utilizada pelo aplicativo e escolha o procedimento de atualização correto abaixo.
- Consulte a Seção 3.2.2.8, “Modificação das Propriedades de Persistência para o Seam Migrado” caso planeje executar seu aplicativo num ambiente com cluster.
3.2.2.5. Mantenha o Comportamento Existente do Valor Gerado Automaticamente da Identidade Hibernate
hibernate.id.new_generator_mappings
que direciona como as colunas de string e identidade são geradas usando o @GeneratedValue
. No JBoss EAP 6, o valor default para esta propriedade é configurado como o seguinte:
- Quando você implanta um aplicativo native Hibernate, o valor default é
false
. - Quando você implanta um aplicativo JPA, o valor default é
true
.
Os novos aplicativos que usam a anotação @GeneratedValue
devem determinar o valor para a propriedade hibernate.id.new_generator_mappings
para true
. Esta é a configuração preferida uma vez que ela é mais portátil entre bancos de dados diferentes. Na maioria das vezes ela é mais eficiente e, na maioria dos casos, ela endereça compatibilidade com a especificação JPA 2.
- Para novos aplicativos JPA, o JBoss EAP 6 padroniza a propriedade
hibernate.id.new_generator_mappings
paratrue
e isto não deve ser alterado. - Para novos aplicativos native Hibernate, o JBoss EAP 6 padroniza a propriedade
hibernate.id.new_generator_mappings
parafalse
. Você deve configurar essa propriedade paratrue
.
Os aplicativos existentes que usam a anotação @GeneratedValue
devem certificar-se de que o mesmo gerador é usado para criar valores de chave primária para novas entidades quando o aplicativo é migrado ao Aplicativo JBoss EAP 6.
- Para aplicativos JPA existentes, o JBoss EAP 6 padroniza a propriedade
hibernate.id.new_generator_mappings
paratrue
. Você deve configurar esta propriedade parafalse
no arquivopersistence.xml
. - Para aplicativos native Hibernate, o JBoss EAP 6 padroniza o
hibernate.id.new_generator_mappings
parafalse
e isto não deve ser alterado.
3.2.2.6. Migração de seu Aplicativo Hibernate 3.3.x para o Hibernate 4.x
Mapeie os tipos de
text
Hibernate paraJDBC LONGVARCHAR
Nas versões anteriores do Hibernate 3.5, o tipo detext
era mapeado paraJDBC CLOB
. Um novo tipo de Hibernate,materialized_clob
, foi adicionado ao Hibernate 4 para mapear as propriedades JavaString
paraJDBC CLOB
. Caso o seu aplicativo possuir propriedades configuradas comotype="text"
, que possuem por intenção serem mapeadas paraJDBC CLOB
, o seguinte deve ser realizado:- Caso o seu aplicativo usar arquivos de mapeamento hbm, altere a propriedade para
type="materialized_clob"
. - Caso seu aplicativo usar anotações, você deve substituir
@Type(type = "text")
por@Lob
.
Revise o código para encontrar alterações em tipos de valores retornados
As projeções de critério agregado numérico retornam agora o mesmo tipo de valor de seus counterparts HQL. Como resultado, os tipos de retorno das projeções seguintes noorg.hibernate.criterion
foram alteradas.- Devido às alterações no
CountProjection
,Projections.rowCount()
,Projections.count(propertyName)
eProjections.countDistinct(propertyName)
, as projeçõescount
ecount distinct
retornam agora um valorLong
. - Devido às alterações no
Projections.sum(propertyName)
, as projeçõessum
retornam agora um tipo de valor que depende do tipo de propriedade.Nota
Falha ao modificar o seu código do aplicativo numjava.lang.ClassCastException
.- Para propriedades mapeadas com tipos de número primitivo, Número, Longo ou Curto, o valor Longo é retornado;
- Para propriedades mapeadas como tipos de ponto flutuante primitivo, Duplo ou Flutuante, o valor Duplo é retornado.
3.2.2.7. Migração de seu Aplicativo Hibernate 3.5.x para o Hibernate 4.x
- Mescle a configuração da Anotação na Configuração.Embora o
AnnotationConfiguration
tenha sido substituído, ele não deve afetar a sua migração.Caso você esteja usando um arquivohbm.xml
, você deve estar ciente que o JBoss EAP 6 usa oorg.hibernate.cfg.EJB3NamingStrategy
noAnnotationConfiguration
ao invés doorg.hibernate.cfg.DefaultNamingStrategy
que foi usado em versões anteriores. Isto pode resultar em incompatibilidade de nomeação. Caso você baseie-se na estratégia de nomeação para o default do nome de uma tabela associada (muitos-para-muitos e coleções de elementos), você poderá ver esse problema. Para resolver isto, você pode solicitar ao Hibernate a usar oorg.hibernate.cfg.DefaultNamingStrategy
de legacia chamando oConfiguration#setNamingStrategy
e passando-o aoorg.hibernate.cfg.DefaultNamingStrategy#INSTANCE
. - Modifique os namespaces para estar de acordo com os novos nomes de arquivos do Hibernate DTD, conforme descrito na tabela abaixo.
Tabela 3.5. Tabela de Mapeamento do DTD Namespace
DTD Namespace anterior Novo DTD Namespace http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd http://www.hibernate.org/dtd/hibernate-mapping-3.0.dtd - Modifique as variáveis do ambiente.
- Caso você esteja usando o Oracle e usando as propriedades
materialized_clob
oumaterialized_blob
, a variável de ambiente globalhibernate.jdbc.use_streams_for_binary
deve ser configurada para verdadeiro. - Caso você esteja usando o PostgreSQL e usando as propriedades
CLOB
ouBLOB
, ohibernate.jdbc.use_streams_for_binary
da variável do ambiente global deve ser configurado para falso.
3.2.2.8. Modificação das Propriedades de Persistência para o Seam Migrado
javax.ejb.EJBTransactionRolledbackException: JBAS010361: Failed to deserialize .... Caused by: java.io.InvalidObjectException: could not resolve session factory during session deserialization [uuid=8aa29e74373ce3a301373ce3a44b0000, name=null]Para solucionar esses erros, você pode modificar as propriedades no arquivo de configuração. Na maioria das vezes, este é o arquivo
persistence.xml
. Para aplicativos native Hibernate API, este é o arquivo hibernate.cfg.xml
.
Procedimento 3.15. Configuração das propriedades a serem executadas num ambiente com cluster
- Determine o valor
hibernate.session_factory_name
a um nome único. Este nome deve ser único por todas as implantações de aplicativo na instância do JBoss Enterprise. Por exemplo:<property name="hibernate.session_factory_name" value="jboss-seam-booking.ear_session_factory"/>
- Determine o valor
hibernate.ejb.entitymanager_factory_name
a um nome único. Este nome deve ser único para todas as implantações do aplicativo na instância do JBoss EAP 6.<property name="hibernate.ejb.entitymanager_factory_name" value="seam-booking.ear_PersistenceUnitName"/>
3.2.2.9. Atualização de seu Aplicativo para ficar de acordo com a Especificação JPA 2.0
A especificação JPA 2.0 requer que um contexto de persistência não seja propagado fora da transação JTA. Caso o seu aplicativo use apenas contextos de persistência de transação com escopo, o comportamento é o mesmo que no JBoss EAP 6, assim como era nas versões anteriores do servidor do aplicativo e nenhuma alteração era requerida. No entanto, caso o seu aplicativo usar um extended persistence context (XPC - contexto de persistência estendida) para permitir o enfileiramento ou as modificações de dados em lote, alterações poderão ser necessárias no seu aplicativo.
Caso o seu aplicativo possua um bean de sessão stateful, Bean1
, que use um contexto de persistência estendido e chame um bean de sessão stateless, Bean2
, que usa um contexto de persistência de transação com escopo, espera-se que o seguinte comportamento ocorra:
- Caso o
Bean1
iniciar uma transação JTA e realizar a invocação do métodoBean2
com a transação JTA ativa, o comportamento no JBoss EAP 6 é o mesmo que dos lançamentos anteriores e nenhuma alteração será necessária. - Caso o
Bean1
não inciar uma transação JTA e realizar a invocação do métodoBean2
, o JBoss EAP 6 não propaga o contexto de persistência estendida aoBean2
. Esse comportamento é diferente ao dos lançamentos anteriores que propagavam o contexto de persistência estendido aoBean2
. Caso o seu aplicativo esperar que o contexto de persistência estendido seja propagado ao bean com o gerenciador de entidade transacional, o seu aplicativo precisará ser alterado para realizar a invocação com uma transação JTA ativa.
3.2.2.10. Substituição do Cache de Segundo Nível JPA/Hibernate com o Infinispan
O JBoss Cache foi substituído pelo Infinispan para o cache de segundo nível (2LC) Hibernate. Isso requer uma alteração ao arquivo persistence.xml
. A sintaxe é um pouco diferente, dependendo de você usar o JPA ou o cache de segundo nível Hibernate. Essas amostras assumem que você está usando o Hibernate.
persistence.xml
no JBoss EAP 5.x.
<property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.jbc2.JndiMultiplexedJBossCacheRegionFactory"/> <property name="hibernate.cache.region.jbc2.cachefactory" value="java:CacheManager"/> <property name="hibernate.cache.use_second_level_cache" value="true"/> <property name="hibernate.cache.region.jbc2.cfg.entity" value="mvcc-entity"/> <property name="hibernate.cache.region_prefix" value="services"/>As seguintes etapas usarão esta amostra para configurar o Infinispan no JBoss EAP 6.
Procedimento 3.16. Modificação do arquivo persistence.xml
para uso Infinispan
Configuração Infinispan para o aplicativo JPA no JBoss EAP 6
Esta é a forma de como você especifica as propriedades para arquivo de mesma configuração para o aplicativo JPA usando o Infinispan no JBoss EAP 6:<property name="hibernate.cache.use_second_level_cache" value="true"/>
Além disso, você precisa especificar umshared-cache-mode
com um valor deENABLE_SELECTIVE
ouALL
conforme abaixo:- O
ENABLE_SELECTIVE
é o default e valor recomendado. Isto significa que as entidades não possuem cache a não que você marque-as como com cache.<shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
ALL
significa que as entidades sempre possuem cache mesmo que você as marque sem cache.<shared-cache-mode>ALL</shared-cache-mode>
Configure o Infinispan para o aplicativo Hibernate native no JBoss EAP 6
Isto é como você pode especificar a mesma configuração para o aplicativo Hibernate native usando o Infinispan com o JBoss EAP 6:<property name="hibernate.cache.region.factory_class" value="org.jboss.as.jpa.hibernate4.infinispan.InfinispanRegionFactory"/> <property name="hibernate.cache.infinispan.cachemanager" value="java:jboss/infinispan/container/hibernate"/> <property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup"/> <property name="hibernate.cache.use_second_level_cache" value="true"/>
Você deve adicionar a seguinte dependência ao arquivoMANIFEST.MF
:Manifest-Version: 1.0 Dependencies: org.infinispan, org.hibernate
3.2.2.11. Propriedades do Cache Hibernate
Tabela 3.6. Propriedades
Nome da Propriedade | Descrição |
---|---|
hibernate.cache.region.factory_class |
O nome da classe de um
CacheProvider personalizado.
|
hibernate.cache.use_minimal_puts |
Booliano. Otimiza a operação do cache de segundo nível para minimizar as gravações, ao custo de leituras mais frequentes. Essa configuração é mais útil para caches com cluster, sendo que o Hibernate3 é habilitado por default para as implantações do cache com cluster.
|
hibernate.cache.use_query_cache |
Booliano. Habilita o cache da consulta. As consultas individuais continuam sendo configuradas com o cache.
|
hibernate.cache.use_second_level_cache |
Booliano. Usado para desativar completamente o cache de segundo nível, que é habilitado por default para classes que especificam um mapeamento
<cache> .
|
hibernate.cache.query_cache_factory |
O nome da classe da interface
QueryCache default. O valor default é um StandardQueryCache interno.
|
hibernate.cache.region_prefix |
O prefixo para uso dos nomes de região do cache de segundo nível.
|
hibernate.cache.use_structured_entries |
Booliano. Força o Hibernate a aplicar o store nos dados no cache de segundo nível num formato mais fácil para o usuário.
|
hibernate.cache.default_cache_concurrency_strategy |
Configuração usada para gerar o nome do
org.hibernate.annotations.CacheConcurrencyStrategy default de uso quando tanto o @Cacheable ou @Cache forem usados. O @Cache(strategy="..") é usado para substituir este default.
|
3.2.2.12. Migração para o Validador Hibernate 4
O Validador Hibernate 4.x é uma nova base de código que implementa o JSR 303 - Bean Validation. O processo de migração do Validator 3.x para 4.x é bastante simples, mas existem algumas alterações que devem ser realizadas quando migrando seu aplicativo.
Procedimento 3.17. Você pode precisar executar uma ou mais dessas tarefas
Acesso ao ValidatorFactory default
O JBoss EAP 6 realiza o bind no ValidatorFactory default para o contexto JNDI sob o nomejava:comp/ValidatorFactory
.Compreensão do ciclo de vida da validação trigger
Quando usado em combinação com o Hibernate Core 4, o ciclo de vida baseado na validação é automaticamente habilitado pelo Hibernate Core.- A validação ocorre nas operações
INSERT
,UPDATE
eDELETE
de entidade. - É possível a configuração de grupos a serem validados pelo tipo de evento usando as seguintes propriedades:Os valores dessas propriedades são de vírgula separada, nomes de classe inteiramente qualificada dos grupos a serem validados.
javax.persistence.validation.group.pre-persist
,javax.persistence.validation.group.pre-update
javax.persistence.validation.group.pre-remove
.
Os grupos de validação são um novo recurso de especificação da Validação Bean. Caso não deseje aproveitar as vantagens desse novo recurso, nenhuma alteração é requerida na migração para o Hibernate Validator 4. - É possível desativar o ciclo de vida baseado na validação pela configuração da propriedade
javax.persistence.validation.mode
paranone
. Outros valores válidos para esta propriedade sãoauto
(o default),callback
eddl
.
Configuração de seu aplicativo para uso da validação
- Caso deseje manualmente controlar a validação, é possível criar um Validador em algumas das seguintes maneiras:
- Crie uma instância
Validator
a partir doValidatorFactory
usando o métodogetValidator()
. - Injete as Instâncias do Validador em seu EJB. O bean CDI ou qualquer outro recurso injetável do Java EE.
- É possível usar o
ValidatorContext
retornado peloValidatorFactory.usingContext()
para personalizar sua instância do Validador. Você pode configurar umMessageInterpolator
,TraverableResolver
eConstraintValidatorFactory
personalizado usando o API. Essas interfaces são especificadas na especificação do Bean Validation e são novas ao Hibernate Validator 4.
Modificação do código para uso de novas restrições do Bean Validation
As novas restrições de validação de nível Bean solicitam alterações de código quando migrando ao Hibernate Validator 4.- As restrições nos seguintes pacotes para atualização ao Validador Hibernate 4 devem ser usadas:
javax.validation.constraints
org.hibernate.validator.constraints
- Todas as restrições que existiam no Hibernate Validator 3 continuam disponíveis no Hibernate Validator 4. Para usá-las, é necessário importar a classe especificada e em alguns casos alterar o nome ou tipo de parâmetro de restrição.
Uso de restrição personalizada
No Hibernate Validator 3, é necessária uma restrição personalizada para implantar a interfaceorg.hibernate.validator.Validator
. No Hibernate Validator 4, é necessário implantar a interfacejavax.validation.ConstraintValidator
. Essa interface contém os mesmos métodosinitialize()
eisValid()
da interface anterior, no entanto, o método de assinatura foi alterado. Além disso, a alteraçãoDDL
não é mais suportada no Hibernate Validator 4.
3.2.3. Alterações do JSF
3.2.3.1. Habilitação de Aplicativos para Uso de Versões Antigas do JSF
Caso seu aplicativo usar uma versão antiga do JSF, não será necessária a atualização para a versão JSF 2.0. Ao invés disso, é possível criar um arquivo jboss-deployment-structure.xml
para solicitar que o JBoss EAP 6 use o JSF 1.2 ao invés do JSF 2.0 com a sua implantação de aplicativo. Este descritor de implantação específico do JBoss é usado para controlar o carregador de classe e é posicionado no diretório META-INF/
ou WEB-INF/
do seu WAR, ou no diretório META-INF/
do seu EAR.
jboss-deployment-structure.xml
que adiciona a dependência para o módulo JSF 1.2 e exclui ou previne o carregamento automático do módulo JSF 2.0.
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0"> <deployment> <dependencies> <module name="javax.faces.api" slot="1.2" export="true"/> <module name="com.sun.jsf-impl" slot="1.2" export="true"/> </dependencies> </deployment> <sub-deployment name="jboss-seam-booking.war"> <exclusions> <module name="javax.faces.api" slot="main"/> <module name="com.sun.jsf-impl" slot="main"/> </exclusions> <dependencies> <module name="javax.faces.api" slot="1.2"/> <module name="com.sun.jsf-impl" slot="1.2"/> </dependencies> </sub-deployment> </jboss-deployment-structure>
3.2.4. Alterações dos Serviços da Web
3.2.4.1. Alterações dos Serviços da Web
- Alterações do Projeto JBossWS API
- Os componentes SPI e Comuns foram fabricados novamente no JBossWS 4. A seguinte tabela lista o API e as alterações de empacotamento que podem afetar a sua migração do aplicativo.
Tabela 3.7. Tamanho das Propriedades do Manuseador de Log
JAR antigo Pacote antigo Novo JAR Novo pacote JBossWS SPI org.jboss.wsf.spi.annotation.* JBossWS API org.jboss.ws.api.annotation.* JBossWS SPI org.jboss.wsf.spi.binding.* JBossWS API org.jboss.ws.api.binding.* JBossWS SPI org.jboss.wsf.spi.management.recording.* JBossWS API org.jboss.ws.api.monitoring.* JBossWS SPI org.jboss.wsf.spi.tools.* JBossWS API org.jboss.ws.api.tools.* JBossWS SPI org.jboss.wsf.spi.tools.ant.* JBossWS API org.jboss.ws.tools.ant.* JBossWS SPI org.jboss.wsf.spi.tools.cmd.* JBossWS API org.jboss.ws.tools.cmd.* JBossWS SPI org.jboss.wsf.spi.util.ServiceLoader JBossWS API org.jboss.ws.api.util.ServiceLoader JBossWS Common org.jboss.wsf.common.* JBossWS API org.jboss.ws.common.* JBossWS Common org.jboss.wsf.common.handler.* JBossWS API org.jboss.ws.api.handler.* JBossWS Common org.jboss.wsf.common.addressing.* JBossWS API org.jboss.ws.api.addressing.* JBossWS Common org.jboss.wsf.common.DOMUtils JBossWS API org.jboss.ws.api.util.DOMUtils JBossWS Native org.jboss.ws.annotation.EndpointConfig JBossWS API org.jboss.ws.api.annotation.EndpointConfig - @WebContext Annotation
- No JBossWS 3.4.x, esta anotação foi empacotada como
org.jboss.wsf.spi.annotation.WebContext
no projeto JBossWS SPI. No JBossWS 4.0, esta anotação foi movida aoorg.jboss.ws.api.annotation.WebContext
no projeto do JBossWS API. Caso o seu aplicativo incluir uma dependência, você deve substituir as importações e dependências no código de fonte do aplicativo e compilá-las em relação ao novo JBossWS API JAR.Existe também uma mudança num atributo que não é compatível com versões anteriores. O atributoString[] virtualHosts
foi alterado paraString virtualHost
. No JBoss EAP 6, você pode especificar apenas um host virtual por implantação. Caso diversos serviços da web usarem a anotação@WebContext
, o valor do virtualHost deve ser idêntico a todos os pontos de extremidade definidos no arquivo de implantação. - Configuração do Ponto de Extremidade
- O JBossWS 4.0 fornece integração da pilha dos JBoss Web Services com a maioria dos módulos do projeto Apache CXF. A camada de integração permite o uso de webservices APIs padrões, incluindo o JAX-WS. Isto permite também o uso dos recursos avançados do Apache CX na parte superior do contêiner do JBoss EAP 6 sem requerer montagem ou configuração complexa.O subsistema
webservice
na configuração domain do JBoss EAP 6 inclui configurações do ponto de extremidade pré-definidos. Você pode definir também suas próprias configurações do ponto de extremidade adicional. A anotação@org.jboss.ws.api.annotation.EndpointConfig
é usada para referenciar uma configuração do ponto de extremidade gerado.Refira-se ao capítulo Serviços JAX-WS Web no Guia de Desenvolvimento do JBoss EAP 6 a partir do https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/ para maiores informações sobre este respeito. - jboss-webservices.xml Deployment Descriptor
- O JBossWS 4.0 introduz um novo descritor de implantação para configurar os serviços da web. O arquivo
jboss-webservices.xml
fornece informação adicional para a implantação gerada e substitui parcialmente o arquivojboss.xml
obsoleto.Para as implantações do EJB webservice, o local esperado para o arquivo do descritorjboss-webservices.xml
está no diretórioMETA-INF/
. Para os pontos de extremidade do POJO e EJB webservice empacotados no arquivo WAR, o local esperado do arquivojboss-webservices.xml
está no diretórioWEB-INF/
.Segue abaixo uma amostra do arquivo do descritorjboss-webservices.xml
e uma tabela descrevendo os elementos.<webservices> <context-root>foo<context-root> <config-name>Standard WSSecurity Endpoint</config-name> <config-file>META-INF/custom.xml</config-file> <property> <name>prop.name</name> <value>prop.value</value> </property> <port-component> <ejb-name>TestService</ejb-name> <port-component-name>TestServicePort</port-component-name> <port-component-uri>/*</port-component-uri> <auth-method>BASIC</auth-method> <transport-guarantee>NONE</transport-guarantee> <secure-wsdl-access>true</secure-wsdl-access> </port-component> <webservice-description> <webservice-description-name>TestService</webservice-description-name> <wsdl-publish-location>file:///bar/foo.wsdl</wsdl-publish-location> </webservice-description> </webservices>
Tabela 3.8. Descrição do Elemento do Arquivo jboss-webservice.xml
Nome do Elemento Descrição context-rootUsado para personalizar a raiz do contexto da implantação dos webservices.config-nameconfig-fileUsado para associar uma implantação do ponto de extremidade com uma configuração do ponto de extremidade gerado. As configurações do ponto de extremidade são especificadas no arquivo de configuração referenciados ou num subsistemawebservices
da configuração do domain.propriedadeUsado para configurar os pares do valor do nome de propriedade simples para configurar o comportamento da pilha webservice.port-componentUsado para personalizar o URI de destinação do ponto de extremidade ou para configurar as propriedades relacionadas com a segurança.webservice-descriptionUsado para personalizar ou substituir o local publicado do webservice WSDL.
3.2.5. Alterações JAX-RS e RESTEasy
3.2.5.1. Configuração das Alterações JAX-RS e RESTEasy
web.xml
deve ser removida por completo e substituí-la por uma das três opções abaixo:
- Subclassifique o
javax.ws.rs.core.Application
e use a anotação@ApplicationPath
.Esta é a opção mais fácil e não requer qualquer configuração xml. Apenas subclassifique ojavax.ws.rs.core.Application
em seu aplicativo e anote-o com o caminho que deseja para disponibilizar as classes JAX-RS. Por exemplo:@ApplicationPath("/mypath") public class MyApplication extends Application { }
Na amostra acima, os seus recursos JAX-RS estão disponíveis no caminho/MY_WEB_APP_CONTEXT/mypath/
.Nota
Perceba que o caminho deve ser especificado como/mypath
e não/mypath/*
. Não deve ter nenhum asterísco ou barra. - Subclassifique
javax.ws.rs.core.Application
e use o arquivoweb.xml
para configurar o mapeamento JAX-RS.Caso não deseje usar a anotação@ApplicationPath
, será necessário subclassificar da mesma forma ojavax.ws.rs.core.Application
. Então, será necessário configurar o mapeamento JAX-RS no arquivoweb.xml
. Por exemplo:public class MyApplication extends Application { }
<servlet-mapping> <servlet-name>com.acme.MyApplication</servlet-name> <url-pattern>/hello/*</url-pattern> </servlet-mapping>
Na amostra acima, os seus recursos JAX-RS estão disponíveis no/MY_WEB_APP_CONTEXT/hello
do caminho.Nota
É possível usar também esta abordagem para substituir um caminho de aplicativo que foi configurado usando a anotação@ApplicationPath
. - Modificação do arquivo
web.xml
.Caso deseje subclassificar oApplication
, é possível configurar o mapeamento JAX-RS no arquivoweb.xml
, conforme abaixo:<servlet-mapping> <servlet-name>javax.ws.rs.core.Application</servlet-name> <url-pattern>/hello/*</url-pattern> </servlet-mapping>
Na amostra acima, os seus recursos JAX-RS estão disponíveis no/MY_WEB_APP_CONTEXT/hello
do caminho.Nota
Caso escolha esta opção, será necessário apenas adicionar o mapeamento. Não é necessário adicionar o servlet correspondente. O servidor é responsável pela adição do servlet correspondente automaticamente.
3.2.6. Alterações do Realm de Segurança LDAP
3.2.6.1. Configuração das Alterações LDAP Security Realm
<application-policy>
no arquivo login-config.xml
. No JBoss EAP 6, o LDAP security realm é configurado no elemento <security-domain>
no arquivo do servidor do aplicativo. Para um servidor autônomo, este é o arquivo standalone/configuration/standalone.xml
. Caso você esteja executando o seu servidor num managed domain, este é o arquivo domain/configuration/domain.xml
.
login-config.xml
do JBoss EAP 5:
<application-policy name="mcp_ldap_domain"> <authentication> <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required"> <module-option name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</module-option> <module-option name="java.naming.security.authentication">simple</module-option> .... </login-module> </authentication> </application-policy>
<subsystem xmlns="urn:jboss:domain:security:1.2"> <security-domains> <security-domain name="mcp_ldap_domain" cache-type="default"> <authentication> <login-module code="org.jboss.security.auth.spi.LdapLoginModule" flag="required"> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/> <module-option name="java.naming.security.authentication" value="simple"/> ... </login-module> </authentication> </security-domain> </security-domains> </subsystem>
Nota
<module-option name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</module-option>Agora, as opções de módulo devem ser especificadas como atributos de elemento com "value=" conforme abaixo:
<module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
3.2.7. Alterações do HornetQ
3.2.7.1. HornetQ e NFS
- O cache do cliente do Red Hat Enterprise Linux NFS deve ser desabilitado.
Importante
Importante
libaio
seja instalado no sistema do Red Hat Enterprise Linux onde o JBoss EAP 6 está sendo executado.
3.2.7.2. Configuração do JMS Bridge para Migração de JMS Messages Existentes ao JBoss EAP 6
3.2.7.3. Criação do JMS Bridge
O JMS bridge consome mensagens a partir de uma fila ou tópico JMS de fonte e os envia a uma fila ou tópico JMS de destino, que normalmente encontra-se em um servidor diferente. Isto pode ser usado para aplicar o bridge entre os servidores JMS, contanto que eles sejam compatíveis com o JMS 1.1. Os recursos JMS de fonte e destinação são observados usando o JNDI e as classes de cliente para a busca JNDI devem ser empacotadas num módulo. O nome do módulo é então declarado numa configuração JMS bridge.
Procedimento 3.18. Criação do JMS Bridge
Configuração do Bridge no Servidor do JBoss EAP 5.x de Fonte
Para evitar conflitos nas classes entre os lançamentos, você deve seguir essas etapas para configurar o JMS bridge no JBoss EAP 5.x. Os nomes do diretório SAR e o bridge são arbitrários e podem ser alterados se você preferir.- Crie um diretório de implementação do JBoss EAP 5 para conter o SAR, por exemplo:
EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/
. - Crie um subdiretório nomeado
META-INF
noEAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/
. - Crie um arquivo
jboss-service.xml
no diretórioEAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/META-INF/
. Ele deve conter informação similar à seguinte amostra.<server> <loader-repository> com.example:archive=unique-archive-name <loader-repository-config>java2ParentDelegation=false</loader-repository-config> </loader-repository> <!-- JBoss EAP 6 JMS Provider --> <mbean code="org.jboss.jms.jndi.JMSProviderLoader" name="jboss.messaging:service=JMSProviderLoader,name=EnterpriseApplicationPlatform6JMSProvider"> <attribute name="ProviderName">EnterpriseApplicationPlatform6JMSProvider</attribute> <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute> <attribute name="FactoryRef">jms/RemoteConnectionFactory</attribute> <attribute name="QueueFactoryRef">jms/RemoteConnectionFactory</attribute> <attribute name="TopicFactoryRef">jms/RemoteConnectionFactory</attribute> <attribute name="Properties"> java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory java.naming.provider.url=remote://EnterpriseApplicationPlatform6host:4447 java.naming.security.principal=jbossuser java.naming.security.credentials=jbosspass </attribute> </mbean> <mbean code="org.jboss.jms.server.bridge.BridgeService" name="jboss.jms:service=Bridge,name=MyBridgeName" xmbean-dd="xmdesc/Bridge-xmbean.xml"> <depends optional-attribute-name="SourceProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends> <depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=EnterpriseApplicationPlatform6JMSProvider</depends> <attribute name="SourceDestinationLookup">/queue/A</attribute> <attribute name="TargetDestinationLookup">jms/queue/test</attribute> <attribute name="QualityOfServiceMode">1</attribute> <attribute name="MaxBatchSize">1</attribute> <attribute name="MaxBatchTime">-1</attribute> <attribute name="FailureRetryInterval">60000</attribute> <attribute name="MaxRetries">-1</attribute> <attribute name="AddMessageIDInHeader">false</attribute> <attribute name="TargetUsername">jbossuser</attribute> <attribute name="TargetPassword">jbosspass</attribute> </mbean> </server>
Nota
O elementoload-repository
está presente para garantir que o SAR possui um classloader isolado. Além disso, perceba que ambos bridge "destino" e busca JNDI incluem as credenciais para o usuário "jbossuser" com a senha "jbosspass". Isto é devido ao JBoss EAP 6 ser segurado por default. O usuário nomeado "jbossuser" com a senha "jbosspass" foi criado noApplicationRealm
com a funçãoguest
usando o scriptEAP_HOME/bin/add_user.sh
. - Copie os seguintes JARs a partir do diretório
EAP_HOME/modules/system/layers/base/
no diretórioEAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/
. Substitua cada VERSION_NUMBER pelo número de versão em sua distribuição do JBoss EAP 6.org/hornetq/main/hornetq-core-VERSION_NUMBER.jar
org/hornetq/main/hornetq-jms-VERSION_NUMBER.jar
org/jboss/ejb-client/main/jboss-ejb-client-VERSION_NUMBER.jar
org/jboss/logging/main/jboss-logging-VERSION_NUMBER.jar
org/jboss/logmanager/main/jboss-logmanager-VERSION_NUMBER.jar
org/jboss/marshalling/main/jboss-marshalling-VERSION_NUMBER.jar
org/jboss/marshalling/river/main/jboss-marshalling-river-VERSION_NUMBER.jar
org/jboss/remote-naming/main/jboss-remote-naming-VERSION_NUMBER.jar
org/jboss/remoting3/main/jboss-remoting-VERSION_NUMBER.jar
org/jboss/sasl/main/jboss-sasl-VERSION_NUMBER.jar
org/jboss/netty/main/netty-VERSION_NUMBER.jar
org/jboss/remoting3/remote-jmx/main/remoting-jmx-VERSION_NUMBER.jar
org/jboss/xnio/main/xnio-api-VERSION_NUMBER.jar
org/jboss/xnio/nio/main.xnio-nio-VERSION_NUMBER.jar
Nota
Não copie simplesmente oEAP_HOME/bin/client/jboss-client.jar
uma vez que as classes javax API classes entrarão em conflito com aquelas do JBoss EAP 5.x.
Configuração do Bridge no Servidor do JBoss EAP 6 de Destinação
No JBoss EAP 6.1 e versões mais recentes, o JMS bridge pode ser usado para realizar o bridge nas mensagens a partir de qualquer servidor compatível com o JMS 1.1. Uma vez que os recursos JMS de destino e fonte são pesquisados usando o JNDI, as classes de busca JNDI do provedor de mensagem fonte, ou agente da mensagem, devem ser empacotadas num Módulo do JBoss. As seguintes etapas usam o agente de mensagem 'MyCustomMQ' como um exemplo.- Criação do módulo do JBoss para o provedor de mensagem.
- Crie uma estrutura de diretório sob o
EAP_HOME/modules/system/layers/base/
para o novo módulo. O subdiretóriomain/
conterá o cliente JARs e o arquivomodule.xml
. Segue abaixo uma amostra da estrutura do diretório criada para o provedor de mensagem MyCustomMQ:EAP_HOME/modules/system/layers/base/org/mycustommq/main/
- No subdiretório
main/
, crie um arquivomodule.xml
contendo a definição do módulo para o provedor de mensagem. Segue abaixo uma amostra domodule.xml
criado para o provedor de mensagem MyCustomMQ.<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.1" name="org.mycustommq"> <properties> <property name="jboss.api" value="private"/> </properties> <resources> <!-- Insert resources required to connect to the source or target --> <resource-root path="mycustommq-1.2.3.jar" /> <resource-root path="mylogapi-0.0.1.jar" /> </resources> <dependencies> <!-- Add the dependencies required by JMS Bridge code --> <module name="javax.api" /> <module name="javax.jms.api" /> <module name="javax.transaction.api"/> <!-- Add a dependency on the org.hornetq module since we send --> <!-- messages tothe HornetQ server embedded in the local EAP instance --> <module name="org.hornetq" /> </dependencies> </module>
- Copie a mensagem dos JARs do provedor de mensagem solicitado para a busca JNDI dos recursos de fonte ao subdiretório
main/
. A estrutura do diretório para o módulo MyCustomMQ deve agora parecer-se com o seguinte.modules/ `-- system `-- layers `-- base `-- org `-- mycustommq `-- main |-- mycustommq-1.2.3.jar |-- mylogapi-0.0.1.jar |-- module.xml
- Configure o JMS bridge no subsistema
messaging
do servidor do JBoss EAP 6.- Antes de começar, interrompa o servidor e realize o backup dos arquivos de configuração do servidor atual. Caso você esteja executando o servidor autônomo, este é o arquivo
EAP_HOME/standalone/configuration/standalone-full-ha.xml
. Caso você esteja executando o managed domain, realize o backup em ambos os arquivosEAP_HOME/domain/configuration/domain.xml
eEAP_HOME/domain/configuration/host.xml
. - Adicione o elemento
jms-bridge
ao subsistemamessaging
no arquivo de configuração do servidor. Os elementossource
etarget
fornecem os nomes dos recursos JMS usados para as buscas JNDI. Caso os credenciaisuser
epassword
forem especificados, eles serão passados como argumentos quando a conexão JMS for criada.Segue abaixo uma amostra do elementojms-bridge
configurado para o provedor de mensagem MyCustomMQ:<subsystem xmlns="urn:jboss:domain:messaging:1.3"> ... <jms-bridge name="myBridge" module="org.mycustommq"> <source> <connection-factory name="ConnectionFactory"/> <destination name="sourceQ"/> <user>user1</user> <password>pwd1</password> <context> <property key="java.naming.factory.initial" value="org.mycustommq.jndi.MyCustomMQInitialContextFactory"/> <property key="java.naming.provider.url" value="tcp://127.0.0.1:9292"/> </context> </source> <target> <connection-factory name="java:/ConnectionFactory"/> <destination name="/jms/targetQ"/> </target> <quality-of-service>DUPLICATES_OK</quality-of-service> <failure-retry-interval>500</failure-retry-interval> <max-retries>1</max-retries> <max-batch-size>500</max-batch-size> <max-batch-time>500</max-batch-time> <add-messageID-in-header>true</add-messageID-in-header> </jms-bridge> </subsystem>
Na amostra acima, as propriedades são definidas no elementocontext
para osource
. Caso o elementocontext
for omitido como na amostratarget
acima, os recursos JMS são bloqueados numa instância local.
3.2.7.4. Migração de seu Aplicativo para uso do HornetQ como um Provedor JMS
Procedimento 3.19. Antes de começar
- Encerre o cliente e o servidor
- Realize uma cópia do backup de quaisquer dados do JBoss Messaging. Os dados da mensagem são stored num banco de dados com tabelas pré-fixadas com o
JBM_
.
Procedimento 3.20. Alteração de seu provedor para o HornetQ
Configurações de transferências
Transfira as configurações do JBoss Messaging à configuração do JBoss EAP 6. As seguintes configurações podem ser encontradas nos descritores de implantação localizados no servidor do JBoss Messaging:- Configuração do Serviço de Criações da ConexõesEsta configuração descreve as criações da conexão JMS implantada com o servidor do JBoss Messaging. O JBoss Messaging configura as criações da conexão num arquivo nomeado
connection-factories-service.xml
, que está localizado no diretório de implantação do servidor do aplicativo. - Configuração de DestinaçãoEsta configuração descreve as filas JMS e tópicos implantados com o servidor do JBoss Messaging. Por default, o JBoss Messaging configura as destinações num arquivo nomeado
destinations-service.xml
que está localizado no diretório de implantação no servidor do aplicativo. - Configuração do Serviço Bridge de MensagemEsta configuração inclui os serviços bridge implantados com o servidor do JBoss Messaging. Nenhum dos bridges são implantados por default, de forma que o nome do arquivo da implantação varia, dependendo de sua instalação.
Modificação de seu código de arquivo
Caso o código do aplicativo usar o JMS default, nenhuma alteração do código será solicitada. No entanto, caso o aplicativo seja conectado a um cluster, você deverá revisar com cuidado a documentação HornetQ das semânticas de clustering. O clustering está fora do escopo da especificação JMS e o HornetQ e o JBoss Messaging tomaram abordagens diferentes em suas respectivas implementações de funcionalidade de clustering.Caso o aplicativo usar recursos específicos do JBoss Messaging, você deverá modificar o código para uso dos recursos equivalentes disponíveis no HornetQ.Para maiores informações sobre a configuração do messaging com o HornetQ, consulte a Seção 3.2.7.5, “Configuração de Mensagens com HornetQ”.Migração de mensagens existentes
Mova quaisquer mensagens do banco de dados do JBoss Messaging ao diário HornetQ usando o JMS bridge. As instruções para configuração do JMS bridge podem ser encontradas na Seção 3.2.7.2, “Configuração do JMS Bridge para Migração de JMS Messages Existentes ao JBoss EAP 6”.
3.2.7.5. Configuração de Mensagens com HornetQ
standalone.xml
ou domain.xml
. Isto é útil, no entanto recomendamos familiarizar-se com os componentes de mensagem dos arquivos de configuração default, sendo que as amostras da documentação usando as ferramentas de gerenciamento fornecem snippets do arquivo de configuração para referência.
3.2.8. Alterações de Clustering
3.2.8.1. Realize Alterações ao seu Aplicativo para o Clustering
Inicie o JBoss EAP 6 com o clustering habilitado
Para habilitar o clustering no JBoss EAP 5.x, era necessário iniciar suas instâncias do servidor usando o perfilall
ou alguma derivação do mesmo, como por exemplo:$ EAP5_HOME/bin/run.sh -c all
No JBoss EAP 6, o método para a habilitação do clustering depende dos servidores serem autônomos ou serem executados num managed domain.Habilitação do cluster para servidores executando num managed domain
Para habilitar o clustering para servidores iniciados usando o domain controller, atualize o seudomain.xml
e determine um grupo de servidor para uso do seu perfilha
e grupo socket bindingha-sockets
. Por exemplo:<server-groups> <server-group name="main-server-group" profile="ha"> <jvm name="default"> <heap size="64m" max-size="512m"/> </jvm> <socket-binding-group ref="ha-sockets"/> </server-group> </server-group>
Habilitação do cluster para servidores autônomos
Inicie o servidor usando o arquivo de configuração apropriado conforme a seguinte amostra de habilitação do cluster para servidores autônomos:$ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME
Especificação do endereço bind
No JBoss EAP 5.x, você normalmente indica o endereço bind usado para clustering usando o argumento da linha de comando-b
, conforme abaixo:$ EAP5_HOME/bin/run.sh -c all -b 192.168.0.2
OJBoss EAP 6 realiza o bind sockets nos endereços IP e interfaces contidas nos elementos<interfaces>
dos arquivosstandalone.xml
,domain.xml
ehost.xml
. As configurações padrões que lançam o JBoss EAP incluem duas configurações de interface:<interfaces> <interface name="management"> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/> </interface> <interface name="public"> <inet-address value="${jboss.bind.address:127.0.0.1}"/> </interface> </interfaces>
Essas configurações de interface usam valores dojboss.bind.address.management
ejboss.bind.address
de propriedades de sistema. Caso as propriedades de sistema não sejam determinadas, o default127.0.0.1
é usado para cada valor.O endereço bind pode ser definido como um argumento da linha de comando quando você inicia o servidor ou você pode explicitamente defini-lo com o arquivo de configuração do servidor do JBoss EAP 6.- Especifique o argumento bind na linha de comando quando iniciando o servidor autônomo do JBoss EAP.Segue abaixo uma amostra de como especificar o endereço bind na linha de comando para o servidor autônomo:
EAP_HOME/bin/standalone.sh -Djboss.bind.address=127.0.0.1
Nota
É possível usar o argumento-b
, que é um atalho para o-Djboss.bind.address=127.0.0.1
:EAP_HOME/bin/standalone.sh -b=127.0.0.1
O formato de sintaxe JBoss EAP 5 também é suportado:
Perceba que o argumentoEAP_HOME/bin/standalone.sh -b 127.0.0.1
-b
apenas modifica as alterações da interfacepublic
. Isto não afeta a interfacemanagement
. - Especifique o endereço bind no arquivo de configuração do servidor.Especifique os endereços bind no arquivo
domain/configuration/host.xml
para servidores executando num managed domain. Para servidores autônomos, especifique os endereços bind no arquivostandalone-ha.xml
.A interfacepublic
na seguinte amostra é especificada como interface default para todos os sockets do grupo socket bindingha-sockets
.<interfaces> <interface name="management"> <inet-address value="192.168.0.2"/> </interface> <interface name="public"> <inet-address value="192.168.0.2"/> </interface> </interfaces>
<socket-binding-groups> <socket-binding-group name="ha-sockets" default-interface="public"> <!-- ... --> </socket-binding-group> </socket-binding-groups>
Nota
Caso o endereço bind for especificado como um valor codificado ao invés de uma propriedade de sistema no arquivo de configuração, não será possível substituí-lo num argumento da linha de comando.
Configure o
jvmRoute
para suportar o mod_jk e mod_proxyNo JBoss EAP 5, o servidor da webjvmRoute
foi configurado usando a propriedade no arquivoserver.xml
. No JBoss EAP 6, o atributojvmRoute
é configurado no subsistema da web do arquivo de combinação do servidor usando o atributoinstance-id
, conforme o seguinte:<subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false" instance-id="{JVM_ROUTE_SERVER}">
O {JVM_ROUTE_SERVER} acima deve ser substituído pela ID do servidor jvmRoute.Oinstance-id
pode ser determinado usando o Management Console.Especificação do endereço multicast e porta
No JBoss EAP 5.x, é possível especificar a porta e o endereço multicast usados para a comunicação de intra-cluste usando os argumentos-u
e-m
da linha de comando, conforme abaixo:$ EAP5_HOME/bin/run.sh -c all -u 228.11.11.11 -m 45688
No JBoss EAP 6, o endereço e porta multicast usados para a comunicação do cluster são definidos pelo socket-binding referenciado pela pilha do protocolo JGroups relevante, conforme abaixo:<subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp"> <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp"/> <!-- ... --> </stack> </subsystem>
<socket-binding-groups> <socket-binding-group name="ha-sockets" default-interface="public"> <!-- ... --> <socket-binding name="jgroups-udp" port="55200" multicast-address="228.11.11.11" multicast-port="45688"/> <!-- ... --> </socket-binding-group> </socket-binding-groups>
Caso você preferir especificar o endereço multicast e a porta na linha de comando, você pode definir o endereço multicast e as portas como propriedades de sistema e usá-las na linha de comando quando você iniciar o servidor. A seguinte amostra,jboss.mcast.addr
é o nome da variável para o endereço multicast e ojboss.mcast.port
é o nome da variável para a porta.<socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.mcast.addr:230.0.0.4}" multicast-port="${jboss.mcast.port:45688}"/>
Você pode iniciar o seu servidor usando os seguintes argumentos da linha de comando:$ EAP_HOME/bin/domain.sh -Djboss.mcast.addr=228.11.11.11 -Djboss.mcast.port=45688
Uso da pilha de protocolo alternativo
No JBoss EAP 5.x, é possível manipular a pilha do protocolo default para todos os serviços de clustering usando a propriedade de sistemajboss.default.jgroups.stack
.$ EAP5_HOME/bin/run.sh -c all -Djboss.default.jgroups.stack=tcp
No JBoss EAP 6, a pilha do protocolo default é definida pelo subsistema JGroups com odomain.xml
oustandalone-ha.xml
:<subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp"> <stack name="udp"> <!-- ... --> </stack> </subsystem>
Substituição da Replicação Buddy
O JBoss EAP 5.x usava o JBoss Cache Buddy Replication para suprimir a replicação de dados de todas as instâncias num cluster.No JBoss EAP 6, o Buddy Replication foi substituído pelo cache distribuído do Infinispan, também conhecido como modoDIST
. A distribuição é um modo de clustering que permite o Infinispan escalar linearmente com mais servidores que são adicionados ao cluster. Segue abaixo uma amostra de como configurar o servidor para uso no modo de DIST caching.- Abra a linha de comando e inicie o servidor com tanto o Perfil Completo ou HA. Por exemplo:
EAP_HOME/bin/standalone.sh -c standalone-ha.xml
- Abra outra linha de comando e conecte-se ao Management CLI.
- Insira a seguinte linha de comando para o Linux:
$ EAP_HOME/bin/jboss-cli.sh --connect
- Insira a seguinte linha de comando para o Windows:
C:\>EAP_HOME\bin\jboss-cli.bat --connect
Você deverá observar a seguinte resposta:Conectado ao controlador autônomo no localhost:9999
- Adicione os seguintes comandos:
/subsystem=infinispan/cache-container=web/:write-attribute(name=default-cache,value=dist) /subsystem=infinispan/cache-container=web/distributed-cache=dist/:write-attribute(name=owners,value=3) :reload
Você deverá ver a seguinte resposta após cada comando:"outcome" => "success"
Esses comandos modificam o elementodist
<distributed-cache>
na configuraçãoweb
<cache-container>
do subsistemainfinispan
do arquivostandalone-ha.xml
, conforme abaixo:<cache-container name="web" aliases="standard-session-cache" default-cache="dist" module="org.jboss.as.clustering.web.infinispan"> <transport lock-timeout="60000"/> <replicated-cache name="repl" mode="ASYNC" batching="true"> <file-store/> </replicated-cache> <replicated-cache name="sso" mode="SYNC" batching="true"/> <distributed-cache name="dist" owners="3" l1-lifespan="0" mode="ASYNC" batching="true"> <file-store/> </distributed-cache> </cache-container>
Refira-se ao capítulo nomeado Clustering nos Aplicativos da Web no Guia de Desenvolvimento do JBoss EAP 6 localizado no Portal do Cliente https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/ para maiores informações a este respeito.
3.2.8.2. Implantação de um HA Singleton
O seguinte procedimento demonstra como implantar um Serviço que está encapsulado com o decorador SingletonService e usado como um serviço singleton amplo com cluster. Este serviço ativa um timer esquematizado, que é iniciado apenas uma vez no cluster.
Procedimento 3.21. Implantação do Serviço HA Singleton
Grave o aplicativo do serviço HA singleton.
Segue abaixo uma amostra de umService
que está encapsulado como decoradorSingletonService
a ser implantado como um serviço singleton. Uma amostra completa pode ser encontrada na iniciação rápidacluster-ha-singleton
que lança o Red Hat JBoss Enterprise Application Platform 6. Esta iniciação rápida contém todas as instruções de construção e implantação do aplicativo.Criação de um serviço.
A lista abaixo é uma amostra de um serviço:package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb; import java.util.Date; import java.util.concurrent.atomic.AtomicBoolean; import javax.naming.InitialContext; import javax.naming.NamingException; import org.jboss.logging.Logger; import org.jboss.msc.service.Service; import org.jboss.msc.service.ServiceName; import org.jboss.msc.service.StartContext; import org.jboss.msc.service.StartException; import org.jboss.msc.service.StopContext; /** * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a> */ public class HATimerService implements Service<String> { private static final Logger LOGGER = Logger.getLogger(HATimerService.class); public static final ServiceName SINGLETON_SERVICE_NAME = ServiceName.JBOSS.append("quickstart", "ha", "singleton", "timer"); /** * A flag whether the service is started. */ private final AtomicBoolean started = new AtomicBoolean(false); /** * @return the name of the server node */ public String getValue() throws IllegalStateException, IllegalArgumentException { LOGGER.infof("%s is %s at %s", HATimerService.class.getSimpleName(), (started.get() ? "started" : "not started"), System.getProperty("jboss.node.name")); return ""; } public void start(StartContext arg0) throws StartException { if (!started.compareAndSet(false, true)) { throw new StartException("The service is still started!"); } LOGGER.info("Start HASingleton timer service '" + this.getClass().getName() + "'"); final String node = System.getProperty("jboss.node.name"); try { InitialContext ic = new InitialContext(); ((Scheduler) ic.lookup("global/jboss-cluster-ha-singleton-service/SchedulerBean!org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.Scheduler")).initialize("HASingleton timer @" + node + " " + new Date()); } catch (NamingException e) { throw new StartException("Could not initialize timer", e); } } public void stop(StopContext arg0) { if (!started.compareAndSet(true, false)) { LOGGER.warn("The service '" + this.getClass().getName() + "' is not active!"); } else { LOGGER.info("Stop HASingleton timer service '" + this.getClass().getName() + "'"); try { InitialContext ic = new InitialContext(); ((Scheduler) ic.lookup("global/jboss-cluster-ha-singleton-service/SchedulerBean!org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.Scheduler")).stop(); } catch (NamingException e) { LOGGER.error("Could not stop timer", e); } } } }
Crie um ativador que instala o
Service
como um clustered singleton com cluster.Segue abaixo uma lista de amostra do ativador de Serviço que instala oHATimerService
como um serviço singleton com cluster:package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb; import org.jboss.as.clustering.singleton.SingletonService; import org.jboss.logging.Logger; import org.jboss.msc.service.DelegatingServiceContainer; import org.jboss.msc.service.ServiceActivator; import org.jboss.msc.service.ServiceActivatorContext; import org.jboss.msc.service.ServiceController; /** * Service activator that installs the HATimerService as a clustered singleton service * during deployment. * * @author Paul Ferraro */ public class HATimerServiceActivator implements ServiceActivator { private final Logger log = Logger.getLogger(this.getClass()); @Override public void activate(ServiceActivatorContext context) { log.info("HATimerService will be installed!"); HATimerService service = new HATimerService(); SingletonService<String> singleton = new SingletonService<String>(service, HATimerService.SINGLETON_SERVICE_NAME); /* * To pass a chain of election policies to the singleton, for example, * to tell JGroups to prefer running the singleton on a node with a * particular name, uncomment the following line: */ // singleton.setElectionPolicy(new PreferredSingletonElectionPolicy(new SimpleSingletonElectionPolicy(), new NamePreference("node2/cluster"))); singleton.build(new DelegatingServiceContainer(context.getServiceTarget(), context.getServiceRegistry())) .setInitialMode(ServiceController.Mode.ACTIVE) .install() ; } }
Nota
A amostra de código acima usa a classe,org.jboss.as.clustering.singleton.SingletonService
, que faz parte do JBoss EAP private API. Um API irá tornar-se disponível no lançamento EAP 7 e a classe privada será preterida, porém estas classes serão mantidas e disponíveis pela duração do ciclo de lançamento do EAP 6.x.Crie um Arquivo ServiceActivator
Crie um arquivo nomeadoorg.jboss.msc.service.ServiceActivator
no diretório do arquivoresources/META-INF/services/
. Adicione uma linha contendo um nome inteiramente qualificado da classe do ServiceActivator criada na etapa anterior.org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator
Crie um Singleton bean que implementa um timer usado como um timer singleton amplo com cluster.
Este Singleton bean não deve possuir uma interface remota e a interface local não deve ser referenciada por outro EJB em qualquer aplicativo. Isto previne uma busca pelo cliente ou outro componente e garante que o SingletonService possua controle total do Singleton.Crie um interface do Esquematizador
package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb; /** * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a> */ public interface Scheduler { void initialize(String info); void stop(); }
Crie um bean do Singleton que implementa o timer do singleton amplo com cluster.
package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb; import javax.annotation.Resource; import javax.ejb.ScheduleExpression; import javax.ejb.Singleton; import javax.ejb.Timeout; import javax.ejb.Timer; import javax.ejb.TimerConfig; import javax.ejb.TimerService; import org.jboss.logging.Logger; /** * A simple example to demonstrate a implementation of a cluster-wide singleton timer. * * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a> */ @Singleton public class SchedulerBean implements Scheduler { private static Logger LOGGER = Logger.getLogger(SchedulerBean.class); @Resource private TimerService timerService; @Timeout public void scheduler(Timer timer) { LOGGER.info("HASingletonTimer: Info=" + timer.getInfo()); } @Override public void initialize(String info) { ScheduleExpression sexpr = new ScheduleExpression(); // set schedule to every 10 seconds for demonstration sexpr.hour("*").minute("*").second("0/10"); // persistent must be false because the timer is started by the HASingleton service timerService.createCalendarTimer(sexpr, new TimerConfig(info, false)); } @Override public void stop() { LOGGER.info("Stop all existing HASingleton timers"); for (Timer timer : timerService.getTimers()) { LOGGER.trace("Stop HASingleton timer: " + timer.getInfo()); timer.cancel(); } } }
Inicie cada instância do JBoss EAP 6 com o clustering habilitado.
Você deve iniciar cada servidor com o perfilHA
, usando um nome de nó único e uma porta de deslocamento para cada instância.- No Linux, use a seguinte sintaxe de comando para iniciar os servidores:
EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME -Djboss.socket.binding.port-offset=PORT_OFFSET
Exemplo 3.1. Inicie os servidores autônomos no Linux
$ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=node1
$ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100
- No Microsoft Windows, use a seguinte sintaxe de comando para iniciar os servidores:
EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME -Djboss.socket.binding.port-offset=PORT_OFFSET
Exemplo 3.2. Inicie os servidores autônomos no Microsoft Windows
C:> EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=node1
C:> EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100
Nota
Caso decida por não usar os argumentos da linha de comando, o arquivostandalone-ha.xml
pode ser configurado para cada instância para efetuar o bind numa interface separada.Implantação do aplicativo aos servidores
O seguinte comando Maven implanta o aplicativo a um servidor executando em portas default.mvn clean install jboss-as:deploy
Para implantação de servidores adicionais, passe o nome do servidor. Caso esteja em um host diferente, passe o nome do host e o número da porta na linha de comando:mvn clean package jboss-as:deploy -Djboss-as.hostname=localhost -Djboss-as.port=10099
Consulte a iniciação rápidacluster-ha-singleton
que lança o JBoss EAP 6 para maiores detalhes da configuração e implantação Maven .
3.2.9. Alterações do Desenvolvimento do Estilo de Serviço
3.2.9.1. Atualização dos Aplicativos que usam as Implantações de Estilo de Serviço
Embora o JBoss EAP 6 não use mais os descritores do estilo de serviço, o contêiner suporta esses serviços de implantações do estilo de serviço evitando o máximo de alterações. Isto significa que se os descritores de implantação jboss-service.xml
ou jboss-beans.xml
forem usados em seu aplicativo do JBoss EAP 5.x, eles devem executar com um pouco ou nenhuma modificação no JBoss EAP 6. É possível empacotar os arquivos no EAR ou SAR ou você pode posicioná-los diretamente no diretório de implantações. Caso esteja executando um servidor autônomo, o diretório de implantações encontra-se no: EAP_HOME/standalone/deployments/
. Caso o managed domain esteja sendo executado, o console ou o CLI devem ser usados para implantar o aplicativo.
3.2.10. Alterações da Invocação Remota
3.2.10.1. Migração dos Aplicativos Implantados do JBoss EAP 5 que realiza Invocações Remotas ao JBoss EAP 6
No JBoss EAP 5, a interface remota do EJB foi limitada ao JNDI, por default, sob o nome "ejbName/local" para interfaces locais e "ejbName/remote" para interfaces remotas. O aplicativo do cliente pesquisa então o bean usando o "ejbName/remote".
ejb:
BEAN_REFERENCE para o acesso remoto aos EJBs com a seguinte sintaxe.
ejb:
BEAN_REFERENCE para os beans stateless:
ejb:<app-name>/<module-name>/<distinct-name>/<bean-name>!<fully-qualified-classname-of-the-remote-interface>Segue abaixo a sintaxe
ejb:
BEAN_REFERENCE para os beans stateful:
ejb:<app-name>/<module-name>/<distinct-name>/<bean-name>!<fully-qualified-classname-of-the-remote-interface>?stateful
<app-name>
- o nome do aplicativo dos EJBs implantados. Isto é tipicamente o nome ear sem o sufixo .ear, no entanto, o nome pode ser substituído no arquivo application.xml. Caso o aplicativo não seja implantado com um .ear, esse valor é um string vazio. Vamos assumir que esta amostra não estava implantada como um EAR.<module-name>
- o nome do módulo dos EJBs implantados no servidor. Isto é tipicamente o nome jar da implantação EJB, sem o sufixo .jar, porém isto pode ser substituído usando o ejb-jar.xml. Nesta amostra, assuma que os EJBs foram implantados num jboss-ejb-remote-app.jar, portanto o nome do módulo é jboss-ejb-remote-app.<distinct-name>
- um nome distinto opcional para o EJB. Esta amostra não usa um nome distinto, portanto isto usa um string vazio.<bean-name>
- por default é um nome de classe simples da classe de implantação do bean.<fully-qualified-classname-of-the-remote-interface>
- o nome da classe inteiramente qualificado de visualização remota.
Assuma que você implantou o seguinte EJB stateless a um servidor do JBoss EAP 6. Perceba que isto o expõe a uma visualização remota para o bean.
@Stateless @Remote(RemoteCalculator.class) public class CalculatorBean implements RemoteCalculator { @Override public int add(int a, int b) { return a + b; } @Override public int subtract(int a, int b) { return a - b; } }No JBoss EAP 5, a pesquisa EJB do cliente e a invocação foi codificada como o seguinte:
InitialContext ctx = new InitialContext(); RemoteCalculator calculator = (RemoteCalculator) ctx.lookup("CalculatorBean/remote"); int a = 204; int b = 340; int sum = calculator.add(a, b);No JBoss EAP 6, a pesquisa do cliente e a invocação com o uso da informação descrita acima, é codificada como o seguinte:
final Hashtable jndiProperties = new Hashtable(); jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); final Context context = new InitialContext(jndiProperties); final String appName = ""; final String moduleName = "jboss-ejb-remote-app"; final String distinctName = ""; final String beanName = CalculatorBean.class.getSimpleName(); final String viewClassName = RemoteCalculator.class.getName(); final RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup("ejb:" + appName + "/" + moduleName + "/" + distinctName + "/" + beanName + "!" + viewClassName); int a = 204; int b = 340; int sum = statelessRemoteCalculator.add(a, b);Caso o seu cliente estiver acessando um EJB stateful, você deve anexar "?stateful" ao final da pesquisa do contexto como abaixo:
final RemoteCalculator statefulRemoteCalculator = (RemoteCalculator) context.lookup("ejb:" + appName + "/" + moduleName + "/" + distinctName + "/" + beanName + "!" + viewClassName + "?stateful")
3.2.10.2. Invocação do Bean de Sessão Remota usando o JNDI
ejb-remote
contém os projetos Maven operantes que demostram essa funcionalidade. A inicialização rápida contém projetos para ambos beans de sessão para implantação e ao cliente remoto.
Pré-requisitos
- Você deve possuir um projeto Maven criado e pronto para uso.
- A configuração para o repositório Maven do JBoss EAP 6 já ter sido adicionada.
- Os beans de sessão que você deseja invocar já terem sido implantados.
- Os beans de sessão implantados devem implantar interfaces comerciais.
- As interfaces comerciais remota dos beans de sessão estão disponíveis como uma dependência Maven. Caso as interfaces comerciais remotas estiverem apenas disponíveis como um arquivo JAR, recomendamos a adição do JAR ao seu repositório Maven como um artefato. Refira-se à documentação Maven para informação
install:install-file
sobre direções, http://maven.apache.org/plugins/maven-install-plugin/usage.html - Você precisa saber do hostname e a porta JNDI do servidor hosting dos beans de sessão.
Procedimento 3.22. Adição da Configuração do Projeto Maven para a Invocação Remota dos Beans de Sessão
Adicione as dependências do projeto solicitadas
Opom.xml
para o projeto deve ser atualizado para incluir as dependências necessárias.Adicione o arquivo
jboss-ejb-client.properties
O API do cliente JBoss EJB espera encontrar um arquivo na raiz do projeto nomeadojboss-ejb-client.properties
que contém a informação da conexão para o serviço JNDI. Adicione este arquivo ao diretóriosrc/main/resources/
de seu projeto com o seguinte conteúdo.# In the following line, set SSL_ENABLED to true for SSL remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false remote.connections=default # Uncomment the following line to set SSL_STARTTLS to true for SSL # remote.connection.default.connect.options.org.xnio.Options.SSL_STARTTLS=true remote.connection.default.host=localhost remote.connection.default.port = 4447 remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false # Add any of the following SASL options if required # remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false # remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false # remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
Altere o portal e o nome do host para coincidir com o seu servidor. O4447
é o número de porta default. Configure a linhaSSL_ENABLED
paratrue
e descomente a linhaSSL_STARTTLS
. A interface remota no contêiner suporta as conexões com e sem segurança usando a mesma porta.Adicione dependências para as interfaces comerciais
Adicione as dependências Maven aopom.xml
para interfaces comerciais remotas dos beans de sessão.<dependency> <groupId>org.jboss.as.quickstarts</groupId> <artifactId>jboss-ejb-remote-server-side</artifactId> <type>ejb-client</type> <version>${project.version}</version> </dependency>
Procedimento 3.23. Obtenção de um Proxy Bean usando o JNDI e Métodos de Invocação do Bean
Manuseio das exceções checadas
Os métodos usados no seguinte código (InitialContext()
elookup()
) possuem uma exceção de checagem do tipojavax.naming.NamingException
. Essas chamadas de método devem tanto ser inseridas num bloco de tentativa/captura que captura oNamingException
ou num método que é declarado ao lançar oNamingException
. A iniciação rápida doejb-remote
usa a segunda técnica.Criação do Contexto JNDI
O objetivo do Contexto JNDI fornece o mecanismo de solicitação de recursos a partir do servidor. Crie um contexto JNDI usando o seguinte código:final Hashtable jndiProperties = new Hashtable(); jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); final Context context = new InitialContext(jndiProperties);
As propriedades de conexão para o serviço JNDI são lidas a partir do arquivojboss-ejb-client.properties
.Uso do método lookup() do Contextp JNDI para obter um proxy de bean
Invoque o métodolookup()
do proxy do bean e passe-o ao nome JNDI do bean de sessão que você requer. Isto retornará um objeto que deve ser convertido ao tipo de interface comercial remota que contém os métodos que você deseje invocar.final RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup( "ejb:/jboss-ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
Os nomes JNDI do bean de sessão são definidos usando uma sintaxe especial. Consulte a Seção 3.2.10.3, “Referência de Nomeação EJB JNDI ” para maiores informações.Métodos de Invocação
Agora que você possui um objeto de bean de proxy, é possível invocar qualquer um dos métodos contidos na interface comercial remota.int a = 204; int b = 340; System.out.println("Adding " + a + " and " + b + " via the remote stateless calculator deployed on the server"); int sum = statelessRemoteCalculator.add(a, b); System.out.println("Remote calculator returned sum = " + sum);
O bean passa a solicitação de invocação do método ao bean de sessão no servidor, onde isto é executado. O resultado é retornado ao bean do proxy que então o retorna ao chamador. A comunicação entre o bean de proxy e o bean de sessão remota é transparente ao chamador.
3.2.10.3. Referência de Nomeação EJB JNDI
ejb:<appName>/<moduleName>/<distinctName>/<beanName>!<viewClassName>?stateful
<appName>
- Caso o arquivo JAR do bean de sessão for implantado com um enterprise archive (EAR - arquivo enterprise), este será o nome do EAR. Por padrão, o nome do EAR é seu filename sem o sufixo
.ear
. O nome do aplicativo pode ser também substituído em seu arquivoapplication.xml
. Caso um bean de sessão não for implantado num EAR, deixe este espaço em branco. <moduleName>
- O nome do módulo é o nome do arquivo JAR que o bean de sessão é implantado. Por padrão, o nome do arquivo JAR é seu próprio filename sem o sufixo
.jar
. O nome do módulo pode ser substituído no arquivoejb-jar.xml
do JAR. <distinctName>
- O JBoss EAP 6 permite que cada implantação especifique um nome distinto opcional. Caso a implantação não possua um nome distinto, por favor deixe isto em branco.
<beanName>
- O nome do bean é o classname do bean de sessão a ser invocado.
<viewClassName>
- A classe de visualização é o classname inteiramente qualificado da interface remota. Isto inclui o nome do pacote da interface.
?stateful
- O sufixo
?stateful
é solicitado quando o nome JNDI refere-se ao bean de sessão stateful. Isto não é incluído para outros tipos de bean.
3.2.11. Alterações EJB 2.x
3.2.11.1. Atualização dos Aplicativos que usam o EJB 2.x
- Inicie o servidor com o perfil completo
- O EJB 2.x Container Managed Persistence (CMP) beans requer o Java Enterprise Edition 6 Full Profile. Este perfil contém elementos de configuração que são necessários para executar o CMP EJBs.Este perfil de configuração contém o módulo de extensão
org.jboss.as.cmp
:<extensions> ... <extension module="org.jboss.as.cmp"/> ... </extensions>
Isto contém o subsistemacmp
:<profiles> ... <subsystem xmlns="urn:jboss:domain:cmp:1.1"/> ... </profiles>
.Para iniciar o servidor autônomo JBoss EAP 6 com o perfil completo, passe o argumento-c standalone-full.xml
ou-c standalone-full-ha.xml
na linha de comando antes de iniciar o servidor. - A configuração do contêiner não é mais suportada
- Nas versões anteriores do JBoss EAP, era possível configurar um contêiner para a entidade CMP e outros beans e usá-lo pela configuração de referências dentro do arquivo do descritor de implantação do aplicativo
jboss.xml
. Por exemplo, haviam configurações diferentes para os beans de sessão no geral.No JBoss EAP 6.x, é possível usar os beans de Entidade EJB 2 com o contêiner padrão. No entanto, as configurações de contêiner diferentes não são mais suportadas. A abordagem recomendada é migrar o EJB2 Stateful Session Beans (SFSB), Stateless Session Beans (SLSB), Message Driven Beans (MDB) para o EJB 3, e para o Container-Managed Persistence (CMP) e Bean-Managed Persistence (BMP) Entity Beans para uso do Java Persistence API (JPA) de acordo com a especificação EJB 3.A configuração do contêiner default no JBoss EAP 6 contém as alterações para os beans EJB 2 CMP:- O bloqueamento pessimista é ativo por default. Isto pode resultar em bloqueios.
- O código de detecção de bloqueio que estava na camada CMP no JBoss EAP 5.x não faz parte do JBoss EAP 6.
No JBoss EAP 5.x, era possível personalizar o caching, pooling,commit-options
e a pilha do interceptor. No JBoss EAP 6, isto não é mais possível. Existe apenas uma implementação, que é parecida à políticaInstância por transação
comcommit-option
C
. Caso você migrar um aplicativo que usa a configuração de contêiner de bean de entidadecmp2.x jdbc2 pm
, que usa o CMP2.x compatível JDBC baseado no gerenciador persistente, haverá um impacto no desempenho. Este contêiner foi optimizado para o desempenho. Recomenda-se a migração destas entidades ao EJB 3 antes de migrar o aplicativo. - Configuração do Interceptor ao lado do Servidor
- O JBoss EAP 6 suporta o Java EE
Interceptor
padrão usando as anotações@Interceptors
e@AroundInvoke
. No entanto, isto não permite a manipulação fora da Segurança ou Transação.Nas versões anteriores do JBoss EAP, era impossível modificar a pilha do interceptor para possuir interceptores personalizados para cada invocação EJB. Isto era normalmente usado para implementar a segurança personalizada ou mecanismos de reentrada, antes das checagens de segurança ou checagem de transação ou criação. O JBoss EAP 6.1 introduziu os interceptores do contêiner para fornecer funcionalidade similar. Para maiores informações sobre os interceptores do contêiner, consulte o capítulo Interceptores do Contêiner no Guia de Desenvolvimento do JBoss EAP.Outra abordagem para fornecer mais controle do que anteriormente, durante ou após a fase de confirmação de uma transação enquanto mantendo a especificação do Java EE, é o uso do Registro de Sincronização da Transação para adição de um ouvinte.O recurso pode ser restaurado usando um dos seguintes métodos:A routina da chamada de retorno deve implementar a Interface- O uso do
InitialContext
TransactionSynchronizationRegistry tsr = (TransactionSynchronizationRegistry) new InitialContext().lookup("java:jboss/TransactionSynchronizationRegistry"); tsr.registerInterposedSynchronization(new MyTxCallback());
- O uso da injeção
@Resource(mappedName = "java:comp/TransactionSynchronizationRegistry") TransactionSynchronizationRegistry tsr; ... tsr.registerInterposedSynchronization(new MyTxCallback());
javax.transaction.Synchronization
. Use o métodobeforeCompletion{}
para executar quaisquer verificações antes da transção ser confirmada ou revertida. Caso umRuntimeException
for lançado a partir deste método, a transação será revertida e o cliente é notificado com umEJBTransactionRolledbackException
. No caso de um XA-Transaction, todos os recursos serão revertidos de acordo com o contrato XA. É possível também habilitar cada lógica comercial dependendo do estado da transação usando o métodoafterCompletion(int txStatus)
. Caso umRuntimeException
seja lançado a partir deste método, a transação permanecerá no estado original, tanto confirmada ou revertida e o cliente não é informado. Apenas o gerente da transação apresenta um aviso nos arquivos de log do servidor. - Configuração ao lado do Servidor para Interceptores ao lado do Cliente
- Nas versões anteriores do JBoss EAP, era possível configurar os interceptores do cliente com a configuração do servidor e fornecer apenas as classes com o cliente API.No JBoss EAP 6, isto não é mais possível uma vez que o Proxy do cliente não é mais criado ao lado do servidor e transmitido ao cliente após a pesquisa. O proxy é agora gerado ao lado do cliente. Esta otimização evita a invocação do servidor para a pesquisa e atualizações da classe.
- Configuração do Pool Bean de Entidade
- A configuração do pool bean de entidade não é recomendada no JBoss EAP 6. Isto deve-se a ela ser limitada à configuração do elemento
<strict-max-pool>
, bloqueios e outros problemas que podem ocorrer caso o pool for muito pequeno para carregar todas as entidades no resultado determinado. Os beans de entidade não possuem métodos grandes de ciclo de vida durante a inicialização, portanto a criação da instância e em volta do contêiner não é mais lenta do que quando usando uma instância de bean de entidade com pool. - Substituição do Arquivo do Descritor de Implementação jboss.xml
- O descritor da implementação
jboss-ejb3.xml
substitui o arquivo do descritor de implantaçãojboss.xml
. Este arquivo é usado para substituir e adicionar os recursos fornecidos pelo Java Enterprise Edition (EE), definido no descritor de implantaçãoejb-jar.xml
. O novo arquivo é incompatível com ojboss.xml
e ojboss.xml
é agora ignorado nas implantações.Por exemplo, nos lançamentos anteriores do JBoss EAP, caso fosse definido um<resource-ref>
no arquivoejb-jar.xml
, você necessitaria de uma definição de recurso correspondente para o nome JNDI no arquivojboss.xml
. O XDoclet gerou automaticamente ambos arquivos do descritor de implantação. No JBoss EAP 6, a informação de mapeamento JNDI é agora definida no arquivojboss-ejb3.xml
. Presuma que a fonte de dados está definida no código de fonte de dados conforme abaixo.DataSource ds1 = (DataSource) new InitialContext().lookup("java:comp/env/jdbc/Resource1"); DataSource ds2 = (DataSource) new InitialContext().lookup("java:comp/env/jdbc/Resource2");
Oejb-jar.xml
define as seguintes referências de recurso.<resource-ref > <res-ref-name>jdbc/Resource1</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref> <resource-ref > <res-ref-name>java:comp/env/jdbc/Resource2</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref>
O arquivojboss-ejb3.jxml
mapeia os nomes JNDI aos recursos usando a seguinte sintaxe XML.<resource-ref> <res-ref-name>jdbc/Resource1</res-ref-name> <jndi-name>java:jboss/datasources/ExampleDS</jndi-name> </resource-ref> <resource-ref> <res-ref-name>java:comp/env/jdbc/Resource2</res-ref-name> <jndi-name>java:jboss/datasources/ExampleDS</jndi-name> </resource-ref>
Algumas das opções de configurações disponíveis no JBoss EAP 5.x do arquvivojboss.xml
não foram implementadas no JBoss EAP 6. A seguinte lista descreve alguns dos atributos usados comumente no arquivojboss.xml
e se há uma maneira alternativa para arquivá-los no JBoss EAP 6.- O elemento
method-attribute
foi usado para configurar uma entidade individual e métodos de beans de sessão.- As opções de configuração
read-only
eidempotent
não estão disponíveis no JBoss EAP 6. - A opção
transaction-timeout
está agora configurada no arquivojboss-ejb3.xml
.
- O atributo
missing-method-permission-exclude-mode
alterou o comportamento dos métodos sem implementação do metadado de segurança explícito num bean com segurança. No JBoss EAP 6, a ausência de uma anotação@RolesAllowed
é normalmente tratada de forma similar ao@PermitAll
- Configuração de Mapeamento de Tipo de Fonte de Dados
- Nas versões anteriores do JBoss EAP, era possível configurar o type-mapping da fonte de dados com o arquivo de configuração de implementação da fonte de dados
*-ds.xml
.No JBoss EAP 6, isto deve ser realizado no arquivo do descritor de implementaçãojbosscmp-jdbc.xml
.<defaults> <datasource-mapping>mySQL</datasource-mapping> <create-table>true</create-table> .... </defaults>
Nas versões anteriores do JBoss EAP, o mapeamento personalizado era feito no arquivostandardjbosscmp-jdbc.xml
. Este arquivo não está mais disponível e o mapeamento é agora realizado no arquivo do descritor de implantaçãojbosscmp-jdbc.xml
.
- Alterações de Coleção e do Interador Container Managed Relationship (CMR)
- Nas versões anteriores do JBoss EAP, era possível para alguns contêiners, como por exemplo o contêiner
cmp2.x jdbc2 pm
, interar as coleções CMR, além de remover e adicionar relações. Isto não é mais possível no JBoss EAP 6, uma vez que a configuração do contêiner não é suportada. Consulte EJB2.1 Finder for CMP entities with relations (CMR) returns duplicates in EAP6 na seção de Soluções de Conhecimento de Suporte do Portal do Cliente, para maiores informações sobre como atingir esta mesma funcionalidade no código do aplicativo. - Entradas duplicadas do Container Managed Relationship (CMR) para Buscas
- Nas versões anteriores do JBoss EAP, era possível selecionar contêineres CMP diferentes que usavam estratégias de persistência diferentes. O contêiner
cmp2.x jdbc2 pm
no JBoss EAP 5.x usava oSQL-92
otimizado para gerar a sintaxe LEFT OUTER JOIN de buscas. A implementação não contém essas otimizações, uma vez que o JBoss EAP 6.x apenas suporta o contêiner para CMP e CMR. A busca deve conter a palavraDISTINCT
na declaraçãoSELECT
para evitar o produto cartesiano no conjunto de resultado. Consulte EJB2.1 Finder for CMP entities with relations (CMR) returns duplicates in EAP6 na seção de Soluções de Conhecimento de Suporte do Portal do Cliente para maiores informações sobre este assunto. - Alteração Default de Exclusão Cascade para os Beans de Entidade CMP
- O valor default de exclusão cascade foi alterado para
false
. Isto pode resultar em falhas de exclusão no JBoss EAP 6. Caso as relações de entidades forem marcadas comocascade-delete
, obatch-cascade-delete
deve ser explicitamente determinado paratrue
no arquivojbosscmp-jdbc.xml
. Consulte cascade delete fail for EJB2 CMP Entities after migration to EAP6 na seção de Soluções de Conhecimento de Suporte no Portal do Cliente para maiores informações. - Mappers Personalizados CMP para Campos Personalizados.
- Caso tenha usado classes mapper tais como
JDBCParameterSetter
,JDBCResultSetReader
eMapper
em seu aplicaitivo do JBoss EAP 5.x, ojava.lang.ClassNotFoundException
será visível na implantação de seu aplicativo ao JBoss EAP 6. Isto é devido aos nomes de pacotes das interfaces terem sido alterados doorg.jboss.ejb.plugins.cmp.jdbc.Mapper
aoorg.jboss.as.cmp.jdbc.Mapper
. Consulte Como usar o mapeamento de Campo para as classes personalizadas num aplicativo EJB2 CMP do EAP6 na seção de Soluções de Conhecimento de Suporte do Portal do Cliente para maiores informações. - Geração de Chaves Primárias usando entity-commands
- Caso seu aplicativo usar o aplicativo do JBoss EAP 5
entity-commands
para gerar chaves primárias, por exemplo:Sequence
ouAuto-increment
, oClassNotFoundException
será visível para a classeJDBCOracleSequenceCreateCommand
quando a migração para o JBoss EAP 6 for realizada. Isto é devido ao pacote da classe ter sido alterado deorg.jboss.ejb.plugins.cmp.jdbc
paraorg.jboss.as.cmp.jdbc.keygen
. Caso deseje usar esta classe no seu aplicativo do JBoss EAP 6, a dependência deve ser adicionada no móduloEAP_HOME/modules/system/layers/base/org/jboss/as/cmp
.
- Modificação do Código para Uso das Novas Regras di JNDI Namespace.
- A partir do EJB 3.0, o uso do prefixo JNDI completo com o EJB 2.x deve ser realizado. Consulte a Seção 3.1.8.1, “Atualização dos Nomes JNDI Namespace do Aplicativo” para maiores informações sobre as novas regras JNDI namespace e amostras de código.Amostras demonstrando como atualizar o JNDI namespace de lançamentos anteriores podem ser encontradas na: Seção 3.1.8.5, “Amostra do JNDI Namespaces nos Lançamentos Anteriores e como são especificados no JBoss EAP 6”.
- Modificação do Descritor do Arquivo
jboss-web.xml
- Modifique o
<jndi-name>
para cada<ejb-ref>
usar o novo formato de pesquisa inteiramente qualificado JNDI. - Use o XDoclet para Mapear o Nome JNDI de Interfaces Locais Internas
- No EJB 2, era bastante comum o uso do
Locator
padrão para observar os Beans. Caso este padrão seja usado em seu aplicativo, o XDoclet pode ser usado para gerar um mapa aos nomes JNDI, ao invés de modificar o código do aplicativo.Uma anotação XDoclet é parecida com o seguinte:@ejb.bean name="UserAttribute" display-name="UserAttribute" local-jndi-name="ejb21/UserAttributeEntity" view-type="local" type="CMP" cmp-version="2.x" primkey-field="id"
O nome JNDIejb21/UserAttributeEntity
na amostra acima não é mais válido no JBoss EAP 6. Você pode mapear este nome a um nome JNDI usando o subsistemanaming
na configuração do servidor e um patch para o XDoclet.Mappers personalizados podem ser criados conforme descrito no parágrafo acima titulado Mappers Personalizados do CMP para Campos Personalizados ou você pode modificar o código conforme descrito no seguinte procedimento.Procedimento 3.24. Alteração do Código Gerado XDoclet e Uso do Subsistema de Nomeação
- Extraia o template XDoclet
lookup.xdt
localizado noejb-module.jar
e modifique olookup()
nolookupHome
conforme abaixo:private static Object lookupHome(java.util.Hashtable environment, String jndiName, Class narrowTo) throws javax.naming.NamingException { // Obtain initial context javax.naming.InitialContext initialContext = new javax.naming.InitialContext(environment); try { // Replace the existing lookup // Object objRef = initialContext.lookup(jndiName); // This is the new mapped lookup Object objRef; try { // try JBoss EAP mapping objRef = initialContext.lookup("global/"+jndiName); } catch(java.lang.Exception e) { objRef = initialContext.lookup(jndiName); } // only narrow if necessary if (java.rmi.Remote.class.isAssignableFrom(narrowTo)) return javax.rmi.PortableRemoteObject.narrow(objRef, narrowTo); else return objRef; } finally { initialContext.close(); } }
- Execute Ant, configurando o atributo do template para uso do
lookup.xdt
modificado para a tarefaejbdoclet
. - Modifique o subsistema
naming
no arquivo da configuração do servidor para mapear o nome JNDI ao novo nome JNDI válido.<subsystem xmlns="urn:jboss:domain:naming:1.2"> <bindings> <lookup name="java:global/ejb21/UserAttributeEntity" lookup="java:global/ejb2CMP/ejb/UserAttribute!de.wfink.ejb21.cmp.cmr.UserAttributeLocalHome"/> </bindings> <remote-naming/> </subsystem>
Os seguintes arquivos não são mais suportados no JBoss EAP 6.
- jboss.xml
- O arquivo do descritor de implantação
jboss.xml
não está mais suportado e será ignorado caso incluído no arquivo implantado. - standardjbosscmp-jdbc.xml
- O arquivo de configuração
standardjbosscmp-jdbc.xml
não é mais suportado. Esta informação de configuração é agora incluída no móduloorg.jboss.as.cmp
e não está mais personalizada. - standardjboss.xml
- O arquivo de configuração
standardjboss.xml
não é mais suportado. A informação de configuração está incluída no arquivostandalone.xml
quando executada num servidor autônomo ou arquivodomain.xml
quando executando num managed domain.
3.2.12. Alterações do JBoss AOP
3.2.12.1. Atualização dos Aplicativos que usam o JBoss AOP
- As configurações EJB3 padrões que eram realizadas anteriormente no arquivo
ejb3-interceptors-aop.xml
são agora configuradas no arquivo de configuração. Isto é um arquivostandalone/configuration/standalone-full.xml
para o servidor autônomo. Caso você esteja executando o seu servidor num managed domain, este é o arquivodomain/configuration/domain.xml
. - Os Interceptores AOP ao lado do servidor devem modificar o uso do Java EE
Interceptor
default. Refira-se ao capítulo Interceptores de Contêiner no Guia de Desenvolvimento do JBoss EAP 6 localizado no Portal do Cliente https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/, para maiores informações sobre os interceptores do contêiner e como usar o interceptor ao lado do cliente.
- Caso você não esteja apto a refatorar o código, você pode obter uma cópia das bibliotecas do JBoss AOP e empacotá-las com o aplicativo. As bibliotecas AOP podem funcionar no JBoss EAP 6, mas não são implantadas. Você pode manualmente implantá-las usando o seguinte argumento da linha de comando, quando você inicia o seu servidor:
-Djboss.aop.path=PATH_TO_AOP_CONFIG
Nota
Embora as bibliotecas do JBoss AOP possam funcionar no JBoss EAP 6, isto não é uma configuração suportada.
3.2.13. Aplicativos Seam 2.2 de Migração
3.2.13.1. Migração dos Arquivos Seam 2.2 para o JBoss EAP 6
Quando você migrar um aplicativo Seam 2.2, você precisa configurar a fonte de dados e especificar quaisquer dependências de módulo. Você precisa determinar também se o aplicativo possui quaisquer dependências em arquivos que não lançam o JBoss EAP 6 e copiar quaisquer JARs dependentes no diretório lib/
do aplicativo.
Importante
Procedimento 3.25. Migração dos Arquivos Seam 2.2
Atualização da configuração da fonte de dados
Algumas das amostras Seam 2.2 usam a fonte de dados JDBC default nomeadajava:/ExampleDS
. A fonte de dados default foi alterada no JBoss EAP 6 parajava:jboss/datasources/ExampleDS
. Caso seu aplicativo usar a fonte de dados da amostra, você pode realizar o seguinte:Consulte a Seção 3.1.6.2, “Atualização da Configuração da Fonte de Dados” para maiores informações de como configurar a fonte de dados.- Caso você deseje usar um banco de dados de amostra que lança o JBoss EAP 6, modifique o arquivo
META-INF/persistence.xml
para substituir o elementojta-data-source
existente com o nome JNDI da fonte de dados do banco de dados de amostra:<!-- <jta-data-source>java:/ExampleDS</jta-data-source> --> <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
- Caso você preferir manter um banco de dados existente, você pode adicionar a definição da fonte de dados ao arquivo
EAP_HOME/standalone/configuration/standalone.xml
.Importante
Você deve interromper o servidor antes de editar o arquivo de configuração do servidor para que sua alteração seja efetivada no reinício do servidor.A seguinte definição é uma cópia da fonte de dados HSQL definida no JBoss EAP 6:<datasource name="ExampleDS" jndi-name="java:/ExampleDS" enabled="true" jta="true" use-java-context="true" use-ccm="true"> <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url> <driver>h2</driver> <security> <user-name>sa</user-name> <password>sa</password> </security> </datasource>
- Você pode também adicionar a definição da fonte de dados usando a interface da linha de comando do Management CLI. Segue abaixo uma amostra da sintaxe que você deve usar para adicionar a fonte de dados. O "\" no final da linha indica a continuação do comando na linha seguinte.
Exemplo 3.3. Amostra da sintaxe para adição da definição da fonte de dados
$ EAP_HOME/bin/jboss-cli --connect [standalone@localhost:9999 /] data-source add --name=ExampleDS --jndi-name=java:/ExampleDS \ --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --driver-name=h2 \ --user-name=sa --password=sa
Adição de quaisquer dependências requeridas
Uma vez que os aplicativos Seam 2.2 usam o JSF 1.2, você precisa adicionar dependências para os módulos JSF 1.2 e excluir os módulos JSF 2.0. Para completar este procedimento, você precisa criar um arquivojboss-deployment-structure.xml
no diretórioMETA-INF/
do EAR que contém os seguintes dados:<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0"> <deployment> <dependencies> <module name="javax.faces.api" slot="1.2" export="true"/> <module name="com.sun.jsf-impl" slot="1.2" export="true"/> </dependencies> </deployment> <sub-deployment name="jboss-seam-booking.war"> <exclusions> <module name="javax.faces.api" slot="main"/> <module name="com.sun.jsf-impl" slot="main"/> </exclusions> <dependencies> <module name="javax.faces.api" slot="1.2"/> <module name="com.sun.jsf-impl" slot="1.2"/> </dependencies> </sub-deployment> </jboss-deployment-structure>
Caso seu aplicativo usar frameworks de registro em log de terceiros, você precisa adicionar as dependências descritas na: Seção 3.1.4.1, “Modificação das Dependências de Registro em Log”.Caso o seu aplicativo usar o Hibernate 3.x, primeiro tente executar o aplicativo usando as bibliotecas do Hibernate 4
Caso o seu aplicativo não usar o Contexto Persistente Gerenciado Seam, busca Hibernate, validação ou quaisquer outros recursos com o Hibernate 4, você pode estar apto a executar com as bibliotecas do Hibernate 4. No entanto, caso você observar oClassNotFoundExceptions
ouClassCastExceptions
que direcionam às classes Hibernate ou verificar erros similares aos seguintes, você terá que seguir as instruções da próxima etapa e modificar o seu aplicativo para uso das bibliotecas do Hibernate 3.3.Caused by: java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.jboss.seam.persistence.HibernateSessionProxy.getSession(Lorg/hibernate/EntityMode;)Lorg/hibernate/Session;" the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, org/jboss/seam/persistence/HibernateSessionProxy, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for interface org/hibernate/Session have different Class objects for the type org/hibernate/Session used in the signature
Cópia dos arquivos dependentes a partir dos frameworks externos ou de outras localizações
Caso o seu aplicativo usar o Hibernate 3.x e você não estiver apto a usar o Hibernate 4 com sucesso no seu aplicativo, você precisará usar uma cópia do Hibernate 3-x JARs no diretório/lib
e excluir o módulo Hibernate na seção de implantações doMETA-INF/jboss-deployment-structure.xml
, conforme o seguinte:<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0"> <deployment> <exclusions> <module name="org.hibernate"/> </exclusions> <deployment> </jboss-deployment-structure>
Não existe nenhuma etapa adicional que você deve realizar quando você aplicar o bundle no seu aplicativo. Consulte a Seção 3.2.2.2, “Configuração das Alterações para Aplicativos que usam o Hibernate e o JPA” para maiores informações.Depuração e resolução dos erros Seam 2.2 JNDI
Quando você migrar o aplicativo Seam 2.2, você poderá ver errosjavax.naming.NameNotFoundException
no log conforme o seguinte:javax.naming.NameNotFoundException: Name 'jboss-seam-booking' not found in context ''
Caso você não deseje modificar as pesquisas JNDI através do código, você pode modificar o arquivocomponents.xml
do aplicativo, conforme abaixo:Substituição do elemento core-init existente
Primeiro, você pode substituir o elemento core-init existente, conforme abaixo:<!-- <core:init jndi-pattern="jboss-seam-booking/#{ejbName}/local" debug="true" distributable="false"/> --> <core:init debug="true" distributable="false"/>
Encontre as mensagens INFO JNDI binding INFO no log do servidor
A seguir, encontre as mensagens INFO binding JNDI que são emitidas no log do servidor quando o aplicativo é implantado. As mensages binding JNIDI devem parecer-se com o seguinte:INFO org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor (MSC service thread 1-1) JNDI bindings for session bean named AuthenticatorAction in deployment unit subdeployment "jboss-seam-booking.jar" of deployment "jboss-seam-booking.ear" are as follows: java:global/jboss-seam-booking/jboss-seam-booking.jar/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator java:app/jboss-seam-booking.jar/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator java:module/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator java:global/jboss-seam-booking/jboss-seam-booking.jar/AuthenticatorAction java:app/jboss-seam-booking.jar/AuthenticatorAction java:module/AuthenticatorAction
Adição dos elementos do componente
Para cada mensagem INFO binding JNIDI, adicione um elementocomponent
correspondente ao arquivocomponents.xml
:<component class="org.jboss.seam.example.booking.AuthenticatorAction" jndi-name="java:app/jboss-seam-booking.jar/AuthenticatorAction" />
Para maiores informações de como depurar e resolver os problemas de migração, consulte a Seção 4.2.1, “Depuração e Solução dos Problemas de Migração”.Para uma lista de problemas de migração conhecidos com os arquivos, consulte a Seção 3.2.13.2, “Problemas de Migração do Seam 2.2 Archive”.
O arquivo Seam 2.2 implementa e é executado com êxito no JBoss EAP 6.
3.2.13.2. Problemas de Migração do Seam 2.2 Archive
- O Seam 2.2 Drools e Java 7 não são compatíveis
- O Seam 2.2 Drools e Java 7 são incompatíveis e falham com um org.drools.RuntimeDroolsException: o valor '1.7' não é um erro de nível de linguagem válido.
- O Seam 2.2.5 determinado como
cglib.jar
não permite o funcionamento da amostra Spring - Quando a amostra Spring estiver executando e usando o
cglib.jar
determinado que lançou o Seam 2.2.5 no JBoss EAP 5, ocorre uma falha com a seguinte causa:java.lang.SecurityException: class "org.jboss.seam.example.spring.UserService$$EnhancerByCGLIB$$7d6c3d12"'s signer information does not match signer information of other classes in the same package
A solução para este problema é sair docglib.jar
, conforme abaixo:zip -d $SEAM_DIR/lib/cglib.jar META-INF/JBOSSCOD\*
- A amostra Seambay falha com o
NotLoggedInException
- A causa deste problema é o cabeçalho da mensagem estar nulo enquanto processando a mensagem no SOAPRequestHandler e, consequentemente, a ID de conversação não ser enviada.A solução para este problema é substituir o
org.jboss.seam.webservice.SOAPRequestHandler.handleOutbound
, conforme descrito no https://issues.jboss.org/browse/JBPAPP-8376. - A amostra Seambay falha com o
UnsupportedOperationException
: nenhuma transação - Este problema é causado pelas alterações no nome JNDI do UserTransaction no JBoss EAP 6.A solução para este problema é substituir o
org.jboss.seam.transaction.Transaction.getUserTransaction
, conforme descrito no https://issues.jboss.org/browse/JBPAPP-8322. - A amostra de tarefas lança o
org.jboss.resteasy.spi.UnhandledException
: não foi possível cancelar o marshall da mensagem solicitada - Este problema é causado pela incompatibilidade entre o seam-resteasy-2.2.5 incluído no JBoss EAP 5.1.2 e o RESTEasy 2.3.1.GA incluído no JBoss EAP 6.Para solucionar este problema use
jboss-deployment-structure.xml
para excluir resteasy-jaxrs, resteasy-jettison-provider e resteasy-jaxb-provider da implantação principal e resteasy-jaxrs, resteasy-jettison-provider, resteasy-jaxb-provider e resteasy-yaml-provider dojboss-seam-tasks.war
, conforme descrito no https://issues.jboss.org/browse/JBPAPP-8315. Então, é necessário incluir as bibliotecas RESTEasy empacotadas com o Seam 2.2 no EAR. - Deadlock entre o
org.jboss.seam.core.SynchronizationInterceptor
e bloqueio EJB da instância de componente stateful durante uma solicitação AJAX - Uma página de erro "Causado pelo javax.servlet.ServletException" é exibida com a mensagem: "javax.el.ELException: /main.xhtml @36,71 value="#{hotelSearch.pageSize}": org.jboss.seam.core.LockTimeoutException: não foi possível adquirir o bloqueio no componente @Synchronized hotelSearch" ou com mensagem de erro similar.O problema é que o Seam 2 realiza o próprio bloqueio fora do bloqueio bean de sessão stateful (SFSB) e com escopo diferente. Isto significa que se um thread acessar um EJB duas vezes na mesma transação, após a primeira invocação isto terá o SFSB bloqueado, mas o seam não será bloqueado. Um segundo thread pode adquirir o bloqueio seam, que então atingirá o bloqueio EJB e entrará em espera. Quando o primeiro thread tentar sua segunda invocação, ele bloqueará no deadlock e interceptor seam 2. No Java EE 5, os EJBs lançariam uma exceção imediatamente no acesso atual. Esse comportamento foi alterado no Java EE 6.Para solucionar este problema, adicione o @AccessTimeout(0) ao EJB. Isto fará com que o
ConcurrentAccessException
seja lançado imediatamente quando esta situação ocorrer. - A amostra Dvdstore cria falhas ordenadas com o
javax.ejb.EJBTransactionRolledbackException
- A amostra do dvdstore exibe o seguinte erro:
JBAS011437: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it. This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context. See JPA spec 2.0 section 7.6.3.1.
Este problema é devido às alterações na especificação JPA.A solução para este problema é alterar o contexto de persistência para otransactional
noCheckoutAction
e classesShowOrdersAction
, além de usar a operação de mesclagem do gerenciador de entidade nos métodoscancelOrder
edetailOrder
. - O provedor do JBoss Cache Seam Cache não pode ser usado no JBoss EAP 6
- O JBoss Cache não é suportado no JBoss EAP 6. Isto leva o provedor do JBoss Cache Seam a falhar no aplicativo Seam do servidor do aplicativo com:
java.lang.NoClassDefFoundError: org/jboss/util/xml/JBossEntityResolver
. - O Hibernate 3.3.x Auto scan para o problema das entidades JPA com o JBoss EAP 6
- A correção para este problema é listar todas as classes no arquivo persistence.xml manualmente. Por exemplo:
<?xml version="1.0" encoding="UTF-8"?> <persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0"> <persistence-unit name="example_pu"> <description>Hibernate 3 Persistence Unit.</description> <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source> <properties> <property name="jboss.as.jpa.providerModule" value="hibernate3-bundled" /> </properties> <class>com.acme.Foo</class> <class>com.acme.Bar</class> </persistence-unit> </persistence>
- A chamada aos componentes EJB Seam para não EJB Threads resulta num javax.naming.NameNotFoundException
- Este problema é o resultado de alterações no JBoss EAP 6 para implantar o novo sistema de carregamento de classe nova modular e para adotar as novas convenções do JNDI namespace padronizado. O
java:app
namespace é designado para os nomes compartilhados por todos os componentes num aplicativo único. Não EE threads, tais como os threads assíncrono Quartz, devem usar ojava:global
namespace, que é compartilhado pelos aplicativos implantados na instância do servidor do aplicativo.Caso você receba umjavax.naming.NameNotFoundException
, quando você tentar chamar os componentes do EJB Seam a partir dos métodos assíncrono Quartz, você deve modificar o arquivocomponents.xml
para uso do nome JNDI global, por exemplo:<component class="org.jboss.seam.example.quartz.MyBean" jndi-name="java:global/seam-quartz/quartz-ejb/myBean"/>
Para maiores informações sobre as alterações do JNDI, refira-se à Seção 3.1.8.1, “Atualização dos Nomes JNDI Namespace do Aplicativo” . Para as maiores informações sobre este problema específico, refira-se ao BZ#948215 - Seam2.3 javax.naming.NameNotFoundException tentando chamar os componentes EJB Seam dos métodos assíncronos quartz nas Notas de Lançamento 2.2.0 para o Red Hat JBoss Web Framework Kit no Portal do Cliente Red Hat .
3.2.14. Aplicativos Spring de Migração
3.2.14.1. Aplicativos Spring de Migração
3.2.15. Outras Alterações que Afetam a Migração
3.2.15.1. Outras alterações que podem afetar sua Migração
3.2.15.2. Alteração do Nome Maven Plug-in
jboss-maven-plugin
não foi atualizado e não funciona no JBoss EAP 6. Você deve usar o org.jboss.as.plugins:jboss-as-maven-plugin
para implantar ao diretório correto.
3.2.15.3. Modificação dos Aplicativos do Cliente
jboss-client.jar
e está localizado no diretório EAP_HOME/bin/client/
. Isto substitui o EAP_HOME/client/jbossall-client.jar
e contém todas as dependências requeridas ao conectar o JBoss EAP 6 a partir do cliente remoto.
Capítulo 4. Ferramentas e Dicas
4.1. Recursos para Assisti-lo com a Migração
4.1.1. Recursos que podem orientá-lo em sua Migração
- Ferramentas
- Existem diversas ferramentas que ajudam automaticamente algumas das alterações da configuração. Consulte a Seção 4.1.2, “Familiarize-se com as Ferramentas que podem orientá-lo na Migração” para maiores informações.
- Dicas de Depuração
- Consulte a Seção 4.2.1, “Depuração e Solução dos Problemas de Migração” para a lista das causas e resoluções de problemas e erros possíveis na migração de seu aplicativo.
- Amostra de Migração
- Consulte a Seção 4.3.1, “Revise a Migração dos Aplicativos de Amostra” para amostras de aplicativos que foram migrados ao JBoss EAP 6.
4.1.2. Familiarize-se com as Ferramentas que podem orientá-lo na Migração
Existem algumas ferramentas que podem assisti-lo no processo de sua migração. Segue abaixo uma lista dessas ferramentas juntamente com a descrição do que elas fazem.
- Tattletale
- Você precisa encontrar e retificar as dependências do aplicativo com a mudança no carregamento de classe modular. O Tattletale pode ajudá-lo a identificar os nomes do módulo de dependência e gerar o XML da configuração para seu aplicativo.
- Ferramenta de Migração IronJacamar
- No JBoss EAP 6, as fontes de dados e adaptadores de recurso não são mais configurados em um arquivo separado. Eles estão apenas definidos no arquivo de configuração do servidor e usam novos esquemas. A Ferramenta de Migração IronJacamar pode ajudar a converter a configuração antiga em um formato esperado pelo JBoss EAP 6.
4.1.3. Uso do Tattle para encontrar Dependências do Aplicativo
Devido às alterações de carregamento de classe no JBoss EAP 6, você poderá ver os traços do ClassNotFoundException
ou ClassCastException
no log do Jboss quando você migrar o seu aplicativo. Para resolver esses erros, você precisa encontrar os JARs que contém as classes especificadas pelas exceções.
jboss-deployment-structure.xml
do aplicativo.
Procedimento 4.1. Instalação e execução do Tattletale para encontrar dependências do aplicativo
Nota
4.1.4. Download e Instalação do Tattletale
Procedimento 4.2. Download e Instalação do Tattletale
- Realize o download da versão 1.2.0.Beta2 do Tattletale ou mais recente a partir do http://sourceforge.net/projects/jboss/files/JBoss%20Tattletale.
- Descomprima o arquivo ao diretório de sua escolha.
- Modifique o arquivo
TATTLETALE_HOME/jboss-tattletale.properties
realizando o seguinte:- Adicione o
ee6
eas7
à propriedadeprofiles
.profiles=java5, java6, ee6, as7
- Descomente as propriedades
scan
ereports
.
4.1.5. Criação e Revisão do Relatório Tattletale
- Crie o relatório Tattletale pela emissão do comando:
java -jar
TATTLETALE_HOME/tattletale.jar
APPLICATION_ARCHIVE
OUTPUT_DIRECTORY
Por exemplo:java -jar tattletale-1.2.0.Beta2/tattletale.jar ~/applications/jboss-seam-booking.ear ~/output-results/
- Num navegador, abra o arquivo
OUTPUT_DIRECTORY/index.html
e clique em "JBoss AS 7" sob a seção "Relatórios".- A coluna na esquerda lista os arquivos usados pelo aplicativo. Clique no link ARCHIVE_NAME para detalhes de visualização sobre o arquivo, tal como sua localização, informação de manifesto e classes que isto contém.
- O link
jboss-deployment-structure.xml
na coluna da direita apresenta como especificar a dependência do módulo para o arquivo nomeado na coluna da esquerda. Clique neste link para verificar como definir a informação do módulo de dependência da implantação para este arquivo.
4.1.6. Uso da Ferramenta IronJacamar para Migração da Fonte de Dados e Configurações do Adaptador de Recurso
Nas versões anteriores do servidor do aplicativo, as fontes de dados e adaptadores de recurso eram configurados e implantados usando um arquivo com sufixo *-ds.xml
. A distribuição IronJacamar 1.1 contém uma ferramenta de migração que pode ser usada para converter esses arquivos de configuração ao formato esperado pelo JBoss EAP 6. As ferramentas analisam o arquivo de configuração da fonte a partir do lançamento anterior, criam e gravam a configuração XML a um arquivo resultante num novo formato. Esse XML pode ser copiado e colado sob o subsistema no arquivo de configuração do servidor do JBoss EAP 6. Essas ferramentas fazem o seu melhor trabalho para converter atributos e elementos antigos em novo formato. No entanto, pode ser necessário realizar modificações adicionais ao arquivo gerado.
Procedimento 4.3. Instalação e execução da ferramenta de Migração IronJacamar
Nota
4.1.7. Download e Instalação da Ferramenta de Migração IronJacamar
Nota
- Realize o download da mais recente distribuição do IronJacamar: http://www.ironjacamar.org/download.html
- Descomprime o arquivo baixado num diretório de sua escolha.
- Encontre o script conversor na distribuição IronJacamar.
- O script Linux está localizado no:
IRONJACAMAR_HOME/doc/as/converter.sh
- O arquivo em lote do Windows está localizado no:
IRONJACAMAR_HOME/doc/as/converter.bat
4.1.8. Uso da Ferramenta de Migração IronJacamar para converter um Arquivo de Configuração da Fonte de Dados
Nota
Procedimento 4.4. Conversão de um Arquivo de Configuração da Fonte de Dados
- Abra uma linha de comandos e navegue ao diretório
IRONJACAMAR_HOME/doc/as/
. - Execute o script conversor digitando o seguinte comando:
- No Linux:
./converter.sh -ds
SOURCE_FILE
TARGET_FILE
- No Microsoft Windows:
./converter.bat -ds
SOURCE_FILE
TARGET_FILE
OSOURCE_FILE
é o arquivo -ds.xml da fonte de dados do lançamento anterior. OTARGET_FILE
contém uma nova configuração.Por exemplo, para converter o arquivo de configuração da fonte de dadosjboss-seam-booking-ds.xml
localizado no diretório atual, você digitaria:- Para o Linux:
./converter.sh -ds
jboss-seam-booking-ds.xml
new-datasource-config.xml
- Para o Microsoft Windows:
./converter.bat -ds
jboss-seam-booking-ds.xml
new-datasource-config.xml
Perceba que o parâmetro para a conversão da fonte de dados é-ds
. - Copie o elemento
<datasource>
a partir do arquivo de destino e cole-o no arquivo de configuração do servidor sob o elemento<subsystem xmlns="urn:jboss:domain:datasources:1.1">
<datasources>
.Importante
Você deve interromper o servidor antes de editar o arquivo de configuração do servidor para que sua alteração seja efetivada no reinício do servidor.- Caso você esteja executando um managed domain, copie o XML ao arquivo
EAP_HOME/domain/configuration/domain.xml
. - Caso você esteja executando num servidor autônomo, copie o XML no arquivo
EAP_HOME/standalone/configuration/standalone.xml
.
- Modificação do XML gerado ao novo arquivo de configuração.Segue abaixo uma amostra do arquivo de configuração da fonte de dados
jboss-seam-booking-ds.xml
para a amostra do Seam 2.2 Booking que foi lançado com o JBoss EAP 5.x:<?xml version="1.0" encoding="UTF-8"?> <datasources> <local-tx-datasource> <jndi-name>bookingDatasource</jndi-name> <connection-url>jdbc:hsqldb:.</connection-url> <driver-class>org.hsqldb.jdbcDriver</driver-class> <user-name>sa</user-name> <password></password> </local-tx-datasource> </datasources>
Segue abaixo o arquivo de configuração que foi gerado pela execução do script conversor. O arquivo gerado contém um elemento<driver-class>
. A maneira preferida de definir a classe do driver no JBoss EAP 6 é usar um elemento<driver>
. Segue abaixo o XML resultando no arquivo de configuração do JBoss EAP 6 com modificações para comentar o elemento<driver-class>
e adicionar o elemento<driver>
:<subsystem xmlns="urn:jboss:domain:datasources:1.1"> <datasources> <datasource enabled="true" jndi-name="java:jboss/datasources/bookingDatasource" jta="true" pool-name="bookingDatasource" use-ccm="true" use-java-context="true"> <connection-url>jdbc:hsqldb:.</connection-url> <!-- Comment out the following driver-class element since it is not the preferred way to define this. <driver-class>org.hsqldb.jdbcDriver</driver-class> --> <!-- Specify the driver, which is defined later in the datasource --> <driver>h2<driver> <transaction-isolation>TRANSACTION_NONE</transaction-isolation> <pool> <prefill>false</prefill> <use-strict-min>false</use-strict-min> <flush-strategy>FailingConnectionOnly</flush-strategy> </pool> <security> <user-name>sa</user-name> <password/> </security> <validation> <validate-on-match>false</validate-on-match> <background-validation>false</background-validation> <use-fast-fail>false</use-fast-fail> </validation> <timeout/> <statement> <track-statements>false</track-statements> </statement> </datasource> <drivers> <!-- The following driver element was not in the XML target file. It was created manually. --> <driver name="h2" module="com.h2database.h2"> <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class> </driver> </drivers> </datasources> </subsystem>
4.1.9. Uso da Ferramenta IronJacamar para Converter um Arquivo de Configuração do Adaptador de Recurso
Nota
- Abra uma linha de comando e navegue ao diretório
IRONJACAMAR_HOME/docs/as/
. - Execute o script conversor digitando o seguinte comando:
- No Linux:
./converter.sh -ra
SOURCE_FILE
TARGET_FILE
- No Microsoft Windows:
./converter.bat -ra
SOURCE_FILE
TARGET_FILE
OSOURCE_FILE
é um arquivo -ds.xml adaptador de recurso do lançamento anterior. OTARGET_FILE
contém uma nova configuração.Por exemplo, para converter o arquivo de configuração do adaptador de recursomttestadapter-ds.xml
localizado no diretório atual, você digitaria:- Para o Linux:
./converter.sh -ra
mttestadapter-ds.xml
new-adapter-config.xml
- Para o Microsoft Windows:
./converter.bat -ra
mttestadapter-ds.xml
new-adapter-config.xml
Perceba que o parâmetro para a conversão do adaptador de recurso é-ra
. - Copie todo o elemento
<resource-adapters>
do arquivo de destino e cole-o no arquivo de configuração sob o elemento<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
Importante
Você deve interromper o servidor antes de editar o arquivo de configuração do servidor para que sua alteração seja efetivada no reinício do servidor.- Caso você esteja executando um managed domain, copie o XML ao arquivo
EAP_HOME/domain/configuration/domain.xml
. - Caso você esteja executando um servidor autônomo, copie o XML ao arquivo
EAP_HOME/standalone/configuration/standalone.xml
.
- Modificação do XML gerado ao novo arquivo de configuração.Segue abaixo um exemplo do arquivo de configuração do adaptador de recurso
mttestadapter-ds.xml
a partir do JBoss EAP 5.x TestSuite:<?xml version="1.0" encoding="UTF-8"?> <!-- ==================================================================== --> <!-- ConnectionManager setup for jboss test adapter --> <!-- Build jmx-api (build/build.sh all) and view for config documentation --> <!-- ==================================================================== --> <connection-factories> <tx-connection-factory> <jndi-name>JBossTestCF</jndi-name> <xa-transaction/> <rar-name>jbosstestadapter.rar</rar-name> <connection-definition>javax.resource.cci.ConnectionFactory</connection-definition> <config-property name="IntegerProperty" type="java.lang.Integer">2</config-property> <config-property name="BooleanProperty" type="java.lang.Boolean">false</config-property> <config-property name="DoubleProperty" type="java.lang.Double">5.5</config-property> <config-property name="UrlProperty" type="java.net.URL">http://www.jboss.org</config-property> <config-property name="sleepInStart" type="long">200</config-property> <config-property name="sleepInStop" type="long">200</config-property> </tx-connection-factory> <tx-connection-factory> <jndi-name>JBossTestCF2</jndi-name> <xa-transaction/> <rar-name>jbosstestadapter.rar</rar-name> <connection-definition>javax.resource.cci.ConnectionFactory</connection-definition> <config-property name="IntegerProperty" type="java.lang.Integer">2</config-property> <config-property name="BooleanProperty" type="java.lang.Boolean">false</config-property> <config-property name="DoubleProperty" type="java.lang.Double">5.5</config-property> <config-property name="UrlProperty" type="java.net.URL">http://www.jboss.org</config-property> <config-property name="sleepInStart" type="long">200</config-property> <config-property name="sleepInStop" type="long">200</config-property> </tx-connection-factory> <tx-connection-factory> <jndi-name>JBossTestCFByTx</jndi-name> <xa-transaction/> <track-connection-by-tx>true</track-connection-by-tx> <rar-name>jbosstestadapter.rar</rar-name> <connection-definition>javax.resource.cci.ConnectionFactory</connection-definition> <config-property name="IntegerProperty" type="java.lang.Integer">2</config-property> <config-property name="BooleanProperty" type="java.lang.Boolean">false</config-property> <config-property name="DoubleProperty" type="java.lang.Double">5.5</config-property> <config-property name="UrlProperty" type="java.net.URL">http://www.jboss.org</config-property> <config-property name="sleepInStart" type="long">200</config-property> <config-property name="sleepInStop" type="long">200</config-property> </tx-connection-factory> </connection-factories>
Segue abaixo o arquivo de configuração que foi gerado pela execução do script conversor. Substitua o valor do atributo do nome da classe "FIXME_MCF_CLASS_NAME" no XML gerado com o nome de classe correto da alocação de conexão gerenciada, neste caso o "org.jboss.test.jca.adapter.TestManagedConnectionFactory". Segue abaixo o XML resultante no arquivo de configuração do JBoss EAP 6 com modificações ao valor do elemento<class-name>
.<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1"> <resource-adapters> <resource-adapter> <archive>jbosstestadapter.rar</archive> <transaction-support>XATransaction</transaction-support> <connection-definitions> <!-- Replace the "FIXME_MCF_CLASS_NAME" class-name value with the correct class name <connection-definition class-name="FIXME_MCF_CLASS_NAME" enabled="true" jndi-name="java:jboss/JBossTestCF" pool-name="JBossTestCF" use-ccm="true" use-java-context="true"> --> <connection-definition class-name="org.jboss.test.jca.adapter.TestManagedConnectionFactory" enabled="true" jndi-name="java:jboss/JBossTestCF" pool-name="JBossTestCF" use-ccm="true" use-java-context="true"> <config-property name="IntegerProperty">2</config-property> <config-property name="sleepInStart">200</config-property> <config-property name="sleepInStop">200</config-property> <config-property name="BooleanProperty">false</config-property> <config-property name="UrlProperty">http://www.jboss.org</config-property> <config-property name="DoubleProperty">5.5</config-property> <pool> <prefill>false</prefill> <use-strict-min>false</use-strict-min> <flush-strategy>FailingConnectionOnly</flush-strategy> </pool> <security> <application/> </security> <timeout/> <validation> <background-validation>false</background-validation> <use-fast-fail>false</use-fast-fail> </validation> </connection-definition> </connection-definitions> </resource-adapter> <resource-adapter> <archive>jbosstestadapter.rar</archive> <transaction-support>XATransaction</transaction-support> <connection-definitions> <!-- Replace the "FIXME_MCF_CLASS_NAME" class-name value with the correct class name <connection-definition class-name="FIXME_MCF_CLASS_NAME" enabled="true" jndi-name="java:jboss/JBossTestCF2" pool-name="JBossTestCF2" use-ccm="true" use-java-context="true"> --> <connection-definition class-name="org.jboss.test.jca.adapter.TestManagedConnectionFactory" enabled="true" jndi-name="java:jboss/JBossTestCF2" pool-name="JBossTestCF2" use-ccm="true" use-java-context="true"> <config-property name="IntegerProperty">2</config-property> <config-property name="sleepInStart">200</config-property> <config-property name="sleepInStop">200</config-property> <config-property name="BooleanProperty">false</config-property> <config-property name="UrlProperty">http://www.jboss.org</config-property> <config-property name="DoubleProperty">5.5</config-property> <pool> <prefill>false</prefill> <use-strict-min>false</use-strict-min> <flush-strategy>FailingConnectionOnly</flush-strategy> </pool> <security> <application/> </security> <timeout/> <validation> <background-validation>false</background-validation> <use-fast-fail>false</use-fast-fail> </validation> </connection-definition> </connection-definitions> </resource-adapter> <resource-adapter> <archive>jbosstestadapter.rar</archive> <transaction-support>XATransaction</transaction-support> <connection-definitions> <!-- Replace the "FIXME_MCF_CLASS_NAME" class-name value with the correct class name <connection-definition class-name="FIXME_MCF_CLASS_NAME" enabled="true" jndi-name="java:jboss/JBossTestCFByTx" pool-name="JBossTestCFByTx" use-ccm="true" use-java-context="true"> --> <connection-definition class-name="org.jboss.test.jca.adapter.TestManagedConnectionFactory" enabled="true" jndi-name="java:jboss/JBossTestCFByTx" pool-name="JBossTestCFByTx" use-ccm="true" use-java-context="true"> <config-property name="IntegerProperty">2</config-property> <config-property name="sleepInStart">200</config-property> <config-property name="sleepInStop">200</config-property> <config-property name="BooleanProperty">false</config-property> <config-property name="UrlProperty">http://www.jboss.org</config-property> <config-property name="DoubleProperty">5.5</config-property> <pool> <prefill>false</prefill> <use-strict-min>false</use-strict-min> <flush-strategy>FailingConnectionOnly</flush-strategy> </pool> <security> <application/> </security> <timeout/> <validation> <background-validation>false</background-validation> <use-fast-fail>false</use-fast-fail> </validation> </connection-definition> </connection-definitions> </resource-adapter> </resource-adapters> </subsystem>
4.2. Problemas da Migração de Depuração
4.2.1. Depuração e Solução dos Problemas de Migração
4.2.2. Depuração e Solução do ClassNotFoundExceptions e NoClassDefFoundErrors
O ClassNotFoundExceptions ocorre normalmente devido a uma dependência não-resolvida. Isto significa que você deve definir explicitamente as dependências em outros módulos ou copiar os JARs de fontes externas.
- Primeiro, tente encontrar a dependência ausente. Maioires informações podem ser encontradas na Seção 4.2.3, “Busque a Dependência de Módulo do JBoss”
- Caso não exista um módulo para a classe ausente, procure pelo JAR na instalação anterior. Para maiores informações, consulte a Seção 4.2.4, “Busca do JAR na Instalação Anterior”
4.2.3. Busque a Dependência de Módulo do JBoss
ClassNotFoundException
pesquisando no diretório EAP_HOME/modules/system/layers/base/
. Caso você encontrar um módulo para a classe, você deve adicionar a dependência à entrada do manifesto.
Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.Log from [Module "deployment.TopicIndex.war:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188)Encontre o módulo do JBoss contendo essa classe efetuando o seguinte:
Procedimento 4.5. Encontre a Dependência
- Determine primeiramente se existe um módulo claro para a classe.
- Navegue ao diretório
EAP_HOME/modules/system/layers/base/
e busque pelo caminho do módulo combinando a classe nomeada noClassNotFoundException
.Você pode encontrar oorg/apache/commons/logging/
de caminho modular. - Abra o arquivo
EAP_HOME/modules/system/layers/base/org/apache/commons/logging/main/module.xml
e encontre o nome do módulo. Neste caso, isto é "org.apache.commons.logging". - Adicione o nome do módulo às Dependências no arquivo
MANIFEST.MF
:Manifest-Version: 1.0 Dependencies: org.apache.commons.logging
- Caso não haja caminho de módulo óbvio para a classe, você precisa encontrar a dependência em outra localização.
- Busque pela classe nomeada no
ClassNotFoundException
do Relatório Tattletale. - Busque o módulo contendo o JAR no diretório
EAP_HOME/modules
e encontre o nome do módulo como na etapa anterior.
4.2.4. Busca do JAR na Instalação Anterior
lib/
anterior do servidor.
ClassNotFoundException
no log:
Caused by: java.lang.NoClassDefFoundError: org/hibernate/validator/ClassValidator at java.lang.Class.getDeclaredMethods0(Native Method)Busque pelo JAR contendo essa classe efetuando o seguinte:
- Abra o terminal e navegue ao diretório
EAP5_HOME/
. - Emita o comando:
grep 'org.hibernate.validator.ClassValidator' `find . \-name '*.jar'`
- Você poderá encontrar mais de um resultado. Neste caso, o seguinte resultado é o JAR que precisamos:
Binary file ./jboss-eap-5.1/seam/lib/hibernate-validator.jar matches
- Copie esse JAR ao diretório
lib/
do aplicativo.Caso precise de um número grande de JARs, pode ser mais fácil definir um módulo para as classes. Refira-se aos Módulos no capítulo nomeado Iniciação dos Aplicativos de Desenvolvimento no Guia de Desenvolvimento para o JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/. - Reconstrua e reimplante o aplicativo.
4.2.5. Depuração e Resolução dos ClassCastExceptions
- Busque pelo aplicativo para encontrar todos os JAR(s) que contém a classe nomeada pelo
ClassCastException
. Caso exista um módulo definido para a classe, encontre e remova os JAR(s) duplicados a partir do WAR ou EAR do aplicativo. - Encontre o módulo do JBoss contendo a classe e defina explicitamente a dependência no arquivo
MANIFEST.MF
ou no arquivojboss-deployment-structure.xml
. Refira-se ao Carregamento de Classe e Subimplantações no capítulo nomeado Carregamento de Classe e Módulos no Guia de Desenvolvimento para o JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/. - Caso não esteja apto a resolver isto usando as etapas acima, é possível determinar normalmente a causa do problema imprimindo a informação do carregador da classe ao log. Por exemplo, será possível observar o seguinte
ClassCastException
no log:java.lang.ClassCastException: com.example1.CustomClass1 não foi possível converter ao com.example2.CustomClass2
- No seu código, imprima a informação do carregador das classes nomeados pelo
ClassCastException
ao log, por exemplo:logger.info("Class loader for CustomClass1: " + com.example1.CustomClass1.getClass().getClassLoader().toString()); logger.info("Class loader for CustomClass2: " + com.example2.CustomClass2.getClass().getClassLoader().toString());
- A informação no log apresenta quais módulos são carregados nas classes e, baseado no seu aplicativo, será necessário remover ou mover os JAR(s) em conflito.
4.2.6. Depuração e Solução do DuplicateServiceExceptions
- Renomeie o arquivo JAR a um nome que é diferente ao WAR, de forma que a web gerada e os contextos WAR sejam únicos.
- Forneça um elemento
<context-root>
ao arquivojboss-web.xml
. - Forneça um elemento
<context-root>
ao arquivojboss-webservices.xml
. - Personalize o elemento
<context-root>
para o WAR no arquivoapplication.xml
.
4.2.7. Depuração e Resolução dos Erros da Página de Depuração do JBoss Seam
Figura 4.1. Página de Depuração do JBoss Seam
- Expanda a seção
Component
na página e procure pelo componenteorg.jboss.seam.caughtException
. - A causa e o traço da pilha devem orientá-lo às dependências ausentes.
Figura 4.2. Informação
org.jboss.seam.caughtException
do componente - Use a técnica descrita na Seção 4.2.2, “Depuração e Solução do ClassNotFoundExceptions e NoClassDefFoundErrors” para resolver as dependências do módulo.Na amostra acima, a solução mais simples é adicionar
org.slf4j
aoMANIFEST.MF
Manifest-Version: 1.0 Dependencies: org.slf4j
Outra opção é adicionar uma dependência para o módulo ao arquivojboss-deployment-structure.xml
:<jboss-deployment-structure> <deployment> <dependencies> <module name="org.slf4j" /> </dependencies> </deployment> </jboss-deployment-structure>
4.3. Revise a Migração dos Aplicativos de Amostra
4.3.1. Revise a Migração dos Aplicativos de Amostra
Segue abaixo uma lista dos aplicativos de amostra do JBoss EAP 5.x que foram migrados ao JBoss EAP 6. Para visualizar os detalhes de como a alteração aconteceu num aplicativo em particular, clique no link abaixo.
4.3.2. Migração da Amostra Seam 2.2 JPA para o JBoss EAP 6
A seguinte tarefa resume as alterações necessárias para a migração com êxito do aplicativo de amostra do Seam 2.2 JPA ao JBoss EAP 6. Este aplicativo de amostra pode ser encontrado na mais recente distribuição do JBoss EAP 5 sob EAP5.x_HOME/jboss-eap-5.x/seam/examples/jpa/
Importante
Procedimento 4.6. Migração da amostra Seam 2.2 JPA
Remoção do arquivo jboss-web
Remova o arquivojboss-web.xml
do diretóriojboss-seam-jpa.war/WEB-INF/
. O carregamento da classe definido nojboss-web.xml
é agora o comportamento default.Modificação do arquivo
jboss-seam-jpa.jar/META-INF/persistence.xml
conforme abaixo.- Remova ou comente a propriedade
hibernate.cache.provider_class
no arquivojboss-seam-jpa.war/WEB-INF/classes/META-INF/persistence.xml
:<!-- <property name="hibernate.cache.provider_class" value="org.hibernate.cache.HashtableCacheProvider"/> -->
- Adicione a propriedade do módulo do provedor ao arquivo
jboss-seam-booking.jar/META-INF/persistence.xml
:<property name="jboss.as.jpa.providerModule" value="hibernate3-bundled" />
- Altere a propriedade
jta-data-source
para uso do nome JNDI da fonte de dados JDBC:<jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
Adição das dependências Seam 2.2
Copie os seguintes JARs da biblioteca Seam 2.2,SEAM_HOME/lib/
, ao diretóriojboss-seam-jpa.war/WEB-INF/lib/
:- antlr.jar
- slf4j-api.jar
- slf4j-log4j12.jar
- hibernate-entitymanager.jar
- hibernate-core.jar
- hibernate-annotations.jar
- hibernate-commons-annotations.jar
- hibernate-validator.jar
Criação de um arquivo jboss-deployment-structure para adicionar as dependências restantes
Crie um arquivojboss-deployment-structure.xml
na pastajboss-seam-jpa.war/WEB-INF/
contendo os seguintes dados:<jboss-deployment-structure> <deployment> <exclusions> <module name="javax.faces.api" slot="main"/> <module name="com.sun.jsf-impl" slot="main"/> <module name="org.hibernate" slot="main"/> </exclusions> <dependencies> <module name="org.apache.log4j" /> <module name="org.dom4j" /> <module name="org.apache.commons.logging" /> <module name="org.apache.commons.collections" /> <module name="javax.faces.api" slot="1.2"/> <module name="com.sun.jsf-impl" slot="1.2"/> </dependencies> </deployment> </jboss-deployment-structure>
O aplicativo da amostra Seam 2.2 implanta e executa com êxito no JBoss EAP 6.
4.3.3. Migração da Amostra do Seam 2.2 JPA para o JBoss EAP 6
A migração do Seam 2.2 Booking EAR é mais complicada do que a amostra Seam 2.2 JPA WAR. A documentação para a migração da amostra Seam 2.2 JPA WAR pode ser encontrada na Seção 4.3.2, “Migração da Amostra Seam 2.2 JPA para o JBoss EAP 6”. Para migrar o aplicativo, por favor realize o seguinte:
- Inicialize o JSF 1.2 ao invés do JSF 2 default.
- Empacote versões antigas dos Hibernate JARs ao invés de usar aquelas que lançam o JBoss EAP 6.
- Altere os bindings JNDI para uso da nova sintaxe portátil do Java EE 6 JNDI.
Importante
Procedimento 4.7. Migração da amostra Seam 2.2 Booking
Crie o arquivo
jboss-deployment-structure.xml
Crie um novo arquivo nomeadojboss-deployment-structure.xml
nojboss-seam-booking.ear/META-INF/
e adicione o seguinte conteúdo:<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0"> <deployment> <dependencies> <module name="javax.faces.api" slot="1.2" export="true"/> <module name="com.sun.jsf-impl" slot="1.2" export="true"/> <module name="org.apache.log4j" export="true"/> <module name="org.dom4j" export="true"/> <module name="org.apache.commons.logging" export="true"/> <module name="org.apache.commons.collections" export="true"/> </dependencies> <exclusions> <module name="org.hibernate" slot="main"/> </exclusions> </deployment> <sub-deployment name="jboss-seam-booking.war"> <exclusions> <module name="javax.faces.api" slot="main"/> <module name="com.sun.jsf-impl" slot="main"/> </exclusions> <dependencies> <module name="javax.faces.api" slot="1.2"/> <module name="com.sun.jsf-impl" slot="1.2"/> </dependencies> </sub-deployment> </jboss-deployment-structure>
Modifique o arquivo
jboss-seam-booking.jar/META-INF/persistence.xml
conforme o seguinte.- Remova ou comente a propriedade do hibernate para a classe do provedor do cache:
<!-- <property name="hibernate.cache.provider_class" value="org.hibernate.cache.HashtableCacheProvider"/> -->
- Adicione a propriedade do módulo do provedor ao arquivo
jboss-seam-booking.jar/META-INF/persistence.xml
:<property name="jboss.as.jpa.providerModule" value="hibernate3-bundled" />
- Altere a propriedade
jta-data-source
para uso do nome JNDI da fonte de dados JDBC:<jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
Copie os JARs a partir da distribuição Seam 2.2
Copie os seguintes JARs a partir da distribuição Seam 2.2EAP5.x_HOME/jboss-eap5.x/seam/lib/
no diretóriojboss-seam-booking.ear/lib
.antlr.jar slf4j-api.jar slf4j-log4j12.jar hibernate-core.jar hibernate-entitymanager.jar hibernate-validator.jar hibernate-annotations.jar hibernate-commons-annotations.jar
Altere os nomes de pesquisa JNDI
Altere os strings de pesquisa JNDI no arquivojboss-seam-booking.war/WEB-INF/components.xml
. O JBoss EAP 6 efetua o bind nos EJBs usando as regras de sintaxe portátil JNDI e não é possível usar o jndiPattern que era usado no JBoss EAP 5. Segue abaixo os strings de pesquisa EJB JNDI do aplicativo que devem ser alterados no JBoss EAP 6:java:global/jboss-seam-booking/jboss-seam-booking/HotelSearchingAction!org.jboss.seam.example.booking.HotelSearching java:app/jboss-seam-booking/HotelSearchingAction!org.jboss.seam.example.booking.HotelSearching java:module/HotelSearchingAction!org.jboss.seam.example.booking.HotelSearching java:global/jboss-seam-booking/jboss-seam-booking/HotelSearchingAction java:app/jboss-seam-booking/HotelSearchingAction java:module/HotelSearchingAction
Os strings de pesquisa para os EJBs de framework Seam 2.2 devem ser alteradas conforme abaixo:java:global/jboss-seam-booking/jboss-seam/EjbSynchronizations!org.jboss.seam.transaction.LocalEjbSynchronizations java:app/jboss-seam/EjbSynchronizations!org.jboss.seam.transaction.LocalEjbSynchronizations java:module/EjbSynchronizations!org.jboss.seam.transaction.LocalEjbSynchronizations java:global/jboss-seam-booking/jboss-seam/EjbSynchronizations java:app/jboss-seam/EjbSynchronizations java:module/EjbSynchronizations
É possível usar uma das seguintes abordagens:Adição dos elementos do componente
É possível adicionar umjndi-name
para cada EJB aoWEB-INF/components.xml
:<component class="org.jboss.seam.transaction.EjbSynchronizations" jndi-name="java:app/jboss-seam/EjbSynchronizations"/> <component class="org.jboss.seam.async.TimerServiceDispatcher" jndi-name="java:app/jboss-seam/TimerServiceDispatcher"/> <component class="org.jboss.seam.example.booking.AuthenticatorAction" jndi-name="java:app/jboss-seam-booking/AuthenticatorAction" /> <component class="org.jboss.seam.example.booking.BookingListAction" jndi-name="java:app/jboss-seam-booking/BookingListAction" /> <component class="org.jboss.seam.example.booking.RegisterAction" jndi-name="java:app/jboss-seam-booking/RegisterAction" /> <component class="org.jboss.seam.example.booking.HotelSearchingAction" jndi-name="java:app/jboss-seam-booking/HotelSearchingAction" /> <component class="org.jboss.seam.example.booking.HotelBookingAction" jndi-name="java:app/jboss-seam-booking/HotelBookingAction" /> <component class="org.jboss.seam.example.booking.ChangePasswordAction" jndi-name="java:app/jboss-seam-booking/ChangePasswordAction" />
- É possível modificar o código pela adição da anotação
@JNDIName(value="")
especificando o caminho JNDI. Segue abaixo uma amostra alterada do código bean de sessão stateless. Uma descrição detalhada deste processo pode ser encontrada na documentação de referência Seam 2.2.@Stateless @Name("authenticator") @JndiName(value="java:app/jboss-seam-booking/AuthenticatorAction") public class AuthenticatorAction implements Authenticator { ... }
O aplicativo da amostra Seam 2.2 Booking implanta e executa com êxito no JBoss EAP 6.
4.3.4. Migração do Seam 2.2 Booking Archive ao JBoss EAP 6: Instruções de Etapa-por-Etapa
EAP6_HOME/standalone/deployments
sem nenhuma alteração além da extração dos arquivos. Isto permite a modificação com facilidade das pastas XML contidas com os arquivos quando você se deparar e solucionar problemas.
Importante
Procedimento 4.8. Migração de seu aplicativo
4.3.5. Construção e Implantação da Versão do JBoss EAP 5.X do Seam 2.2 Booking Application
Procedimento 4.9. Construção e implantação do EAR
- Contrução do EAR:
$ cd /EAP5_HOME/jboss-eap5.x/seam/examples/booking $ ANT_HOME/ant explode
Substitua o jboss-eap5.x pela versão do JBoss EAP que a migração está sendo realizada. - Copie o EAR ao diretório de implantações EAP6_HOME:
$ cp -r EAP5_HOME/seam/examples/booking/exploded-archives/jboss-seam-booking.ear EAP6_HOME/standalone/deployments/ $ cp -r EAP5_HOME/seam/examples/booking/exploded-archives/jboss-seam-booking.war EAP6_HOME/standalone/deployments/jboss-seam.ear $ cp -r EAP5_HOME/seam/examples/booking/exploded-archives/jboss-seam-booking.jar EAP6_HOME/standalone/deployments/jboss-seam.ear
- Inicie o servidor do JBoss EAP 6 e verifique o log. Você verá o seguinte:
INFO [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found jboss-seam-booking.ear in deployment directory. To trigger deployment create a file called jboss-seam-booking.ear.dodeploy
- Crie um arquivo vazio com o nome
jboss-seam-booking.ear.dodeploy
e copie-o ao diretórioEAP6_HOME/standalone/deployments
. É necessário copiar este arquivo no diretório de implantações diversas vezes enquanto migrando este aplicativo. Portanto, mantenha isto numa localização possível localizar com facilidade. No log, será possível ver agora as seguintes mensagens indicando que a implantação está ocorrendo:INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "jboss-seam-booking.ear" INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) Starting deployment of "jboss-seam-booking.jar" INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) Starting deployment of "jboss-seam.jar" INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Starting deployment of "jboss-seam-booking.war"
A partir daqui, é possível encontrar o primeiro erro de implantação. A próxima etapa, será possível verificar cada problema e aprender como depurá-lo e resolvê-lo.Consulte a Seção 4.3.6, “Depuração e resolução do erros e exceções do Seam 2.2 Booking Archive Deployment” para maiores informações sobre como depurar e resolver problemas de implantação.Clique na Seção 4.3.4, “Migração do Seam 2.2 Booking Archive ao JBoss EAP 6: Instruções de Etapa-por-Etapa” para retornar ao tópico anterior.
4.3.6. Depuração e resolução do erros e exceções do Seam 2.2 Booking Archive Deployment
Importante
Procedimento 4.10. Depuração e resolução dos erros de implantação e exceções
- Problema - java.lang.ClassNotFoundException: javax.faces.FacesExceptionQuando o aplicativo é implantado, o log contém o seguinte erro:
ERROR \[org.jboss.msc.service.fail\] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.subunit."jboss-seam-booking.ear"."jboss-seam-booking.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."jboss-seam-booking.ear"."jboss-seam-booking.war".POST_MODULE: Failed to process phase POST_MODULE of subdeployment "jboss-seam-booking.war" of deployment "jboss-seam-booking.ear" (.. additional logs removed ...) Caused by: java.lang.ClassNotFoundException: javax.faces.FacesException from \[Module "deployment.jboss-seam-booking.ear:main" from Service Module Loader\] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
O que significa:O ClassNotFoundException indica que falta uma dependência. Neste caso, ele não pode encontrar a classe
javax.faces.FacesException
e é necessário adicionar a dependência.Como resolver isto:Busque pelo nome do módulo para aquela classe no diretório
EAP6_HOME/modules/system/layers/base/
apenas observando o caminho que coincide com a classe faltante. Neste caso, é possível encontrar dois módulos que coincidem com o caminho:javax/faces/api/main javax/faces/api/1.2
Ambos os módulos possuem o mesmo nome de módulo:javax.faces.api
, porém um deles no diretório principal é para o JSF 2.0 e outro localizado no diretório 1.2 é para o JSF 1.2. Caso houvesse apenas um módulo disponível, seria possível simplesmente criar um arquivoMANIFEST.MF
e adicionar a dependência do módulo. Neste caso, a versão JSF 1.2 deve ser usada ao invés da versão 2.0 no principal, de forma que é necessário especificar uma e excluir a outra. Para isto, crie um arquivojboss-deployment-structure.xml
no diretório doMETA-INF/
do EAR que contém os seguintes dados:<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0"> <deployment> <dependencies> <module name="javax.faces.api" slot="1.2" export="true"/> </dependencies> </deployment> <sub-deployment name="jboss-seam-booking.war"> <exclusions> <module name="javax.faces.api" slot="main"/> </exclusions> <dependencies> <module name="javax.faces.api" slot="1.2"/> </dependencies> </sub-deployment> </jboss-deployment-structure>
Na seçãodeployment
, a dependência para ojavax.faces.api
do módulo JSF 1.2 é adicionada. É possível adicionar também a dependência do módulo JSF 1.2 na seção de subimplantação para o WAR e excluir o módulo para o JSF 2.0.Reimplante o aplicativo apenas excluindo o arquivoEAP6_HOME/standalone/deployments/jboss-seam-booking.ear.failed
e criando um arquivojboss-seam-booking.ear.dodeploy
vazio no mesmo diretório. - Problema - java.lang.ClassNotFoundException: org.apache.commons.logging.LogQuando o aplicativo é implantado, o log contém o seguinte erro:
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC00001: Failed to start service jboss.deployment.unit."jboss-seam-booking.ear".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-seam-booking.ear".INSTALL: Failed to process phase INSTALL of deployment "jboss-seam-booking.ear" (.. additional logs removed ...) Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.Log from [Module "deployment.jboss-seam-booking.ear.jboss-seam-booking.war:main" from Service Module Loader]
O que significa:O
ClassNotFoundException
indica a falta de uma dependência. Neste caso, ele não pode buscar a classeorg.apache.commons.logging.Log
e é necessária a adição da dependência.Como resolver isto:Busque pelo nome do módulo para aquela classe no diretório
EAP6_HOME/modules/system/layers/base/
apenas observando o caminho que coincide com a classe faltante. Neste caso, é possível encontrar um módulo que coincide o caminhoorg/apache/commons/logging/
. O nome do módulo é “org.apache.commons.logging”.Modifique o arquivojboss-deployment-structure.xml
e adicione a dependência do módulo à seção de implantação do arquivo.<module name="org.apache.commons.logging" export="true"/>
Ojboss-deployment-structure.xml
deve parecer-se com o seguinte:<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0"> <deployment> <dependencies> <module name="javax.faces.api" slot="1.2" export="true"/> <module name="org.apache.commons.logging" export="true"/> </dependencies> </deployment> <sub-deployment name="jboss-seam-booking.war"> <exclusions> <module name="javax.faces.api" slot="main"/> </exclusions> <dependencies> <module name="javax.faces.api" slot="1.2"/> </dependencies> </sub-deployment> </jboss-deployment-structure>
Reimplante o aplicativo apenas excluindo o arquivoEAP6_HOME/standalone/deployments/jboss-seam-booking.ear.failed
e criando um arquivojboss-seam-booking.ear.dodeploy
vazio no mesmo diretório. - Problema - java.lang.ClassNotFoundException: org.dom4j.DocumentExceptionQuando o aplicativo é implantado, o log contém o seguinte erro:
ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/seam-booking]] (MSC service thread 1-3) Exception sending context initialized event to listener instance of class org.jboss.seam.servlet.SeamListener: java.lang.NoClassDefFoundError: org/dom4j/DocumentException (... additional logs removed ...) Caused by: java.lang.ClassNotFoundException: org.dom4j.DocumentException from [Module "deployment.jboss-seam-booking.ear.jboss-seam.jar:main" from Service Module Loader]
O que significa:O
ClassNotFoundException
indica que falta uma dependência. Neste caso, ele não pode buscar pela classeorg.dom4j.DocumentException
.Como resolver isto:Encontre o nome do módulo no diretório
EAP6_HOME/modules/system/layers/base/
procurando peloorg/dom4j/DocumentException
. O nome do módulo é “org.dom4j”. Modifique o arquivojboss-deployment-structure.xml
para adicionar a dependência do módulo à seção de implantação do arquivo.<module name="org.dom4j" export="true"/>
O arquivojboss-deployment-structure.xml
deve agora parecer-se com o abaixo:<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0"> <deployment> <dependencies> <module name="javax.faces.api" slot="1.2" export="true"/> <module name="org.apache.commons.logging" export="true"/> <module name="org.dom4j" export="true"/> </dependencies> </deployment> <sub-deployment name="jboss-seam-booking.war"> <exclusions> <module name="javax.faces.api" slot="main"/> </exclusions> <dependencies> <module name="javax.faces.api" slot="1.2"/> </dependencies> </sub-deployment> </jboss-deployment-structure>
Reimplante o aplicativo apenas excluindo o arquivoEAP6_HOME/standalone/deployments/jboss-seam-booking.ear.failed
e criando um arquivojboss-seam-booking.ear.dodeploy
vazio no mesmo diretório. - Problema - java.lang.ClassNotFoundException: org.hibernate.validator.InvalidValueQuando o aplicativo é implantado, o log contém o seguinte erro:
ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/seam-booking]] (MSC service thread 1-6) Exception sending context initialized event to listener instance of class org.jboss.seam.servlet.SeamListener: java.lang.RuntimeException: Could not create Component: org.jboss.seam.international.statusMessages (... additional logs removed ...) Caused by: java.lang.ClassNotFoundException: org.hibernate.validator.InvalidValue from [Module "deployment.jboss-seam-booking.ear.jboss-seam.jar:main" from Service Module Loader]
O que significa:O
ClassNotFoundException
indica que falta uma dependência. Neste caso, isto não pode encontrar a classeorg.hibernate.validator.InvalidValue
.Como resolver isto:O módulo existe “org.hibernate.validator”, mas o JAR não possui a classe
org.hibernate.validator.InvalidValue
, portanto a adição da dependência do módulo não resolve este problema. Neste caso, o JAR contendo a classe fazia parte da implantação JBoss EAP 5.X. Pesquise pelo JAR que contém a classe ausente no diretórioEAP5_HOME/seam/lib/
. Para isto, abra o console e digite o seguinte:$ cd EAP5_HOME/seam/lib $ grep 'org.hibernate.validator.InvalidValue' `find . -name '*.jar'`
O resultado apresenta:$ Binary file ./hibernate-validator.jar matches $ Binary file ./test/hibernate-all.jar matches
Neste caso, copie ohibernate-validator.jar
para o diretóriojboss-seam-booking.ear/lib/
$ cp EAP5_HOME/seam/lib/hibernate-validator.jar jboss-seam-booking.ear/lib
Reimplante o aplicativo apenas excluindo o arquivoEAP6_HOME/standalone/deployments/jboss-seam-booking.ear.failed
e criando um arquivojboss-seam-booking.ear.dodeploy
vazio no mesmo diretório. - Problema - java.lang.InstantiationException: org.jboss.seam.jsf.SeamApplicationFactoryQuando o aplicativo é implantado, o log contém o seguinte erro:
INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-7) Unsanitized stacktrace from failed start...: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.application.ApplicationFactory' was not configured properly. at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:296) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4] (... additional logs removed ...) Caused by: javax.faces.FacesException: org.jboss.seam.jsf.SeamApplicationFactory at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:606) [jsf-api-1.2_13.jar:1.2_13-b01-FCS] (... additional logs removed ...) at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:294) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4] ... 11 more Caused by: java.lang.InstantiationException: org.jboss.seam.jsf.SeamApplicationFactory at java.lang.Class.newInstance0(Class.java:340) [:1.6.0_25] at java.lang.Class.newInstance(Class.java:308) [:1.6.0_25] at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:604) [jsf-api-1.2_13.jar:1.2_13-b01-FCS] ... 16 more
O que significa:O
com.sun.faces.config.ConfigurationException
ejava.lang.InstantiationException
indicam um problema de dependência. Neste caso, a causa não é óbvia.Como resolver isto:Pesquise pelo módulo que contém as classes
com.sun.faces
. Enquanto não existir o módulocom.sun.faces
, haverão dois móduloscom.sun.jsf-impl
. Uma checagem rápida dojsf-impl-1.2_13.jar
no diretório 1.2 apresenta que isto contém as classescom.sun.faces
. Assim como nojavax.faces.FacesException
ClassNotFoundException
, o uso da versão JSF 1.2 é recomendada ao invés da versão JSF 2.0 da página principal, portanto uma precisa ser especificada e a outra excluída. A modificação dojboss-deployment-structure.xml
para adição da dependência do módulo é necessária na seção de implantação do arquivo. A adição da mesma é necessária à subimplantação WAR e exclusão do módulo JSF 2.0. O arquivo deve parecer-se com o seguinte:<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0"> <deployment> <dependencies> <module name="javax.faces.api" slot="1.2" export="true"/> <module name="com.sun.jsf-impl" slot="1.2" export="true"/> <module name="org.apache.commons.logging" export="true"/> <module name="org.dom4j" export="true"/> </dependencies> </deployment> <sub-deployment name="jboss-seam-booking.war"> <exclusions> <module name="javax.faces.api" slot="main"/> <module name="com.sun.jsf-impl" slot="main"/> </exclusions> <dependencies> <module name="javax.faces.api" slot="1.2"/> <module name="com.sun.jsf-impl" slot="1.2"/> </dependencies> </sub-deployment> </jboss-deployment-structure>
Reimplante o aplicativo apenas excluindo o arquivoEAP6_HOME/standalone/deployments/jboss-seam-booking.ear.failed
e criando um arquivojboss-seam-booking.ear.dodeploy
vazio no mesmo diretório. - Problema - java.lang.ClassNotFoundException: org.apache.commons.collections.ArrayStackQuando o aplicativo é implantado, o log contém o seguinte erro:
ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/seam-booking]] (MSC service thread 1-1) Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! org.apache.commons.collections.ArrayStack from [Module "deployment.jboss-seam-booking.ear:main" from Service Module Loader] (... additional logs removed ...) Caused by: java.lang.ClassNotFoundException: org.apache.commons.collections.ArrayStack from [Module "deployment.jboss-seam-booking.ear:main" from Service Module Loader]
O que significa:O
ClassNotFoundException
indica que falta uma dependência. Neste caso, ele não pode buscar a classeorg.apache.commons.collections.ArrayStack
.Como resolver isto:Encontre o nome do módulo no diretório
EAP6_HOME/modules/system/layers/base/
procurando pelo caminhoorg/apache/commons/collections
. O nome do módulo é “org.apache.commons.collections”. Modifique ojboss-deployment-structure.xml
para adicionar a dependência do módulo à seção de implantação do arquivo.<module name="org.apache.commons.collections" export="true"/>
O arquivojboss-deployment-structure.xml
deve agora parecer-se com o abaixo:<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0"> <deployment> <dependencies> <module name="javax.faces.api" slot="1.2" export="true"/> <module name="com.sun.jsf-impl" slot="1.2" export="true"/> <module name="org.apache.commons.logging" export="true"/> <module name="org.dom4j" export="true"/> <module name="org.apache.commons.collections" export="true"/> </dependencies> </deployment> <sub-deployment name="jboss-seam-booking.war"> <exclusions> <module name="javax.faces.api" slot="main"/> <module name="com.sun.jsf-impl" slot="main"/> </exclusions> <dependencies> <module name="javax.faces.api" slot="1.2"/> <module name="com.sun.jsf-impl" slot="1.2"/> </dependencies> </sub-deployment> </jboss-deployment-structure>
Reimplante o aplicativo apenas excluindo o arquivoEAP6_HOME/standalone/deployments/jboss-seam-booking.ear.failed
e criando um arquivojboss-seam-booking.ear.dodeploy
vazio no mesmo diretório. - Problema - Serviços com dependências indisponíveis/faltantesQuando o aplicativo é implantado, o log contém o seguinte erro:
ERROR [org.jboss.as.deployment] (DeploymentScanner-threads - 2) {"Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"jboss-seam-booking.ear\".\"jboss-seam-booking.jar\".component.AuthenticatorAction.START missing [ jboss.naming.context.java.comp.jboss-seam-booking.\"jboss-seam-booking.jar\".AuthenticatorAction.\"env/org.jboss.seam.example.booking.AuthenticatorAction/em\" ]","jboss.deployment.subunit.\"jboss-seam-booking.ear\".\"jboss-seam-booking.jar\".component.HotelSearchingAction.START missing [ jboss.naming.context.java.comp.jboss-seam-booking.\"jboss-seam-booking.jar\".HotelSearchingAction.\"env/org.jboss.seam.example.booking.HotelSearchingAction/em\" ]"," (... additional logs removed ...) "jboss.deployment.subunit.\"jboss-seam-booking.ear\".\"jboss-seam-booking.jar\".component.BookingListAction.START missing [ jboss.naming.context.java.comp.jboss-seam-booking.\"jboss-seam-booking.jar\".BookingListAction.\"env/org.jboss.seam.example.booking.BookingListAction/em\" ]","jboss.persistenceunit.\"jboss-seam-booking.ear/jboss-seam-booking.jar#bookingDatabase\" missing [ jboss.naming.context.java.bookingDatasource ]"]}}}
O que significa:Quando o erro “Serviços com dependências ausentes/indisponíveis” aparecer, observe o texto entre parênteses após "missing". Segue abaixo uma amostra:
missing [ jboss.naming.context.java.comp.jboss-seam-booking.\"jboss-seam-booking.jar\".AuthenticatorAction.\"env/org.jboss.seam.example.booking.AuthenticatorAction/em\" ]
O “/em” indica um Gerenciador de Entidade e problema de fonte de dados.Como resolver isto:No JBoss EAP 6, a configuração de fonte de dados foi alterada e precisa ser definida no arquivo
EAP6_HOME/standalone/configuration/standalone.xml
. Uma vez que o JBoss EAP 6 lança uma fonte de dados de amostra que já está definida no arquivostandalone.xml
, modifique o arquivopersistence.xml
para uso da amostra da fonte de dados neste aplicativo. Quando pesquisando no arquivostandalone.xml
, será possível perceber que ojndi-name
para amostra da fonte de dados éjava:jboss/datasources/ExampleDS
. Modifique o arquivojboss-seam-booking.jar/META-INF/persistence.xml
para comentar o elementojta-data-source
existente e substituí-lo pelo o seguinte:<!-- <jta-data-source>java:/bookingDatasource</jta-data-source> --> <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
Reimplante o aplicativo apenas excluindo o arquivoEAP6_HOME/standalone/deployments/jboss-seam-booking.ear.failed
e criando um arquivojboss-seam-booking.ear.dodeploy
vazio no mesmo diretório. - A partir de agora, o aplicativo implanta sem erros, porém quando acessando o URL http://localhost:8080/seam-booking/ num navegador e você tentar "Entrar na Conta", o erro “A página não está sendo redirecionada de forma apropriada” será exibido. Na próxima etapa, será descrito como depurar e resolver os erros do período de execução.Consulte a Seção 4.3.7, “Depuração e Resolução de erros e exceções do Seam 2.2 Booking Archive Runtime” para maiores informações sobre como depurar e resolver problemas do período de execução.Clique na Seção 4.3.4, “Migração do Seam 2.2 Booking Archive ao JBoss EAP 6: Instruções de Etapa-por-Etapa” para retornar ao tópico anterior.
4.3.7. Depuração e Resolução de erros e exceções do Seam 2.2 Booking Archive Runtime
Importante
Procedimento 4.11. Depuração e resolução das exceções e erros do período de execução
- Problema - javax.naming.NameNotFoundException: Name 'jboss-seam-booking' not found in context ''Quando um URL http://localhost:8080/seam-booking/ é acessado num navegador, a mensagem "A página não está sendo redirecionada de forma apropriada" aparece e o log contém o seguinte erro:
SEVERE [org.jboss.seam.jsf.SeamPhaseListener] (http--127.0.0.1-8080-1) swallowing exception: java.lang.IllegalStateException: Could not start transaction at org.jboss.seam.jsf.SeamPhaseListener.begin(SeamPhaseListener.java:598) [jboss-seam.jar:] (... log messages removed ...) Caused by: org.jboss.seam.InstantiationException: Could not instantiate Seam component: org.jboss.seam.transaction.synchronizations at org.jboss.seam.Component.newInstance(Component.java:2170) [jboss-seam.jar:] (... log messages removed ...) Caused by: javax.naming.NameNotFoundException: Name 'jboss-seam-booking' not found in context '' at org.jboss.as.naming.util.NamingUtils.nameNotFoundException(NamingUtils.java:109) (... log messages removed ...)
O que significa:Um
NameNotFoundException
indica um problema de nomeação JNDI. As regras de nomeação JNDI foram alteradas no JBoss EAP 6, de forma que é necessário modificar os nomes de busca para seguir as novas regras.Como resolver isto:Para depurar isto, observe o rastreamento do log servidor antecedente ao que o JNDI binding foi usado. Será possível observar o seguinte no log do servidor:
15:01:16,138 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named RegisterAction in deployment unit subdeployment "jboss-seam-booking.jar" of deployment "jboss-seam-booking.ear" are as follows: java:global/jboss-seam-booking/jboss-seam-booking.jar/RegisterAction!org.jboss.seam.example.booking.Register java:app/jboss-seam-booking.jar/RegisterAction!org.jboss.seam.example.booking.Register java:module/RegisterAction!org.jboss.seam.example.booking.Register java:global/jboss-seam-booking/jboss-seam-booking.jar/RegisterAction java:app/jboss-seam-booking.jar/RegisterAction java:module/RegisterAction [JNDI bindings continue ...]
Existe o total de oito INFO JNDI bindings listados no log, um para cada bean: RegisterAction, BookingListAction, HotelBookingAction, AuthenticatorAction, ChangePasswordAction, HotelSearchingAction, EjbSynchronizations e TimerServiceDispatcher. Será necessário modificar o arquivolib/components.xml
do WAR para usar o novo JNDI bindings. No log, perceba que todos os EJB JNDI bindings iniciam com "java:app/jboss-seam-booking.jar". Substitua o elementocore:init
conforme o seguinte:<!-- <core:init jndi-pattern="jboss-seam-booking/#{ejbName}/local" debug="true" distributable="false"/> --> <core:init jndi-pattern="java:app/jboss-seam-booking.jar/#{ejbName}" debug="true" distributable="false"/>
Em seguida, adicione o EjbSynchronizations e TimerServiceDispatcher JNDI bindings. Adicione os seguintes componentes ao arquivo:<component class="org.jboss.seam.transaction.EjbSynchronizations" jndi-name="java:app/jboss-seam/EjbSynchronizations"/> <component class="org.jboss.seam.async.TimerServiceDispatcher" jndi-name="java:app/jboss-seam/TimerServiceDispatcher"/>
O arquivo components.xml deve parecer-se com o seguinte:<?xml version="1.0" encoding="UTF-8"?> <components xmlns="http://jboss.com/products/seam/components" xmlns:core="http://jboss.com/products/seam/core" xmlns:security="http://jboss.com/products/seam/security" xmlns:transaction="http://jboss.com/products/seam/transaction" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://jboss.com/products/seam/core http://jboss.com/products/seam/core-2.2.xsd http://jboss.com/products/seam/transaction http://jboss.com/products/seam/transaction-2.2.xsd http://jboss.com/products/seam/security http://jboss.com/products/seam/security-2.2.xsd http://jboss.com/products/seam/components http://jboss.com/products/seam/components-2.2.xsd"> <!-- <core:init jndi-pattern="jboss-seam-booking/#{ejbName}/local" debug="true" distributable="false"/> --> <core:init jndi-pattern="java:app/jboss-seam-booking.jar/#{ejbName}" debug="true" distributable="false"/> <core:manager conversation-timeout="120000" concurrent-request-timeout="500" conversation-id-parameter="cid"/> <transaction:ejb-transaction/> <security:identity authenticate-method="#{authenticator.authenticate}"/> <component class="org.jboss.seam.transaction.EjbSynchronizations" jndi-name="java:app/jboss-seam/EjbSynchronizations"/> <component class="org.jboss.seam.async.TimerServiceDispatcher" jndi-name="java:app/jboss-seam/TimerServiceDispatcher"/> </components>
Reimplante o aplicativo apenas excluindo o arquivostandalone/deployments/jboss-seam-booking.ear.failed
e criando um arquivojboss-seam-booking.ear.dodeploy
vazio no mesmo diretório. - Problema - O aplicativo implanta e executa sem o erro. Quando acessando o URL http://localhost:8080/seam-booking/ num navegador e houver a tentativa de login, ocorrerá uma falha com a mensagem "O Login falhou. A transação falhou." Verifique um traço de exceção no log do servidor:
13:36:04,631 WARN [org.jboss.modules] (http-/127.0.0.1:8080-1) Failed to define class org.jboss.seam.persistence.HibernateSessionProxy in Module "deployment.jboss-seam-booking.ear.jboss-seam.jar:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/jboss/seam/persistence/HibernateSessionProxy (Module "deployment.jboss-seam-booking.ear.jboss-seam.jar:main" from Service Module Loader) .... Caused by: java.lang.LinkageError: Failed to link org/jboss/seam/persistence/HibernateSessionProxy (Module "deployment.jboss-seam-booking.ear.jboss-seam.jar:main" from Service Module Loader) ... Caused by: java.lang.NoClassDefFoundError: org/hibernate/engine/SessionImplementor at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_45] ... Caused by: java.lang.ClassNotFoundException: org.hibernate.engine.SessionImplementor from [Module "deployment.jboss-seam-booking.ear.jboss-seam.jar:main" from Service Module Loader] ...
O que significa:O ClassNotFoundException indica a biblioteca Hibernate ausente. Neste caso está no
hibernate-core.jar
.Como resolver isto:Copie o
hibernate-core.jar
JAR a partir no diretórioEAP5_HOME/seam/lib/
ao diretóriojboss-seam-booking.ear/lib
.Reimplante o aplicativo apenas excluindo o arquivostandalone/deployments/jboss-seam-booking.ear.failed
e criando um arquivojboss-seam-booking.ear.dodeploy
vazio no mesmo diretório. - Problema - O aplicativo implanta e executa sem erro. Quando acessando o URL http://localhost:8080/seam-booking/ num navegador, o login poderá ser efetuado com sucesso. No entanto, quando houver a tentiva de reservar um hotel, um traço da exceção poderá ser observado.Para depurar isto, primeiramente remova o
jboss-seam-booking.ear/jboss-seam-booking.war/WEB-INF/lib/jboss-seam-debug.jar
uma vez que isto mascara o erro verdadeiro. Neste caso, o seguinte erro poderá ser observado:java.lang.NoClassDefFoundError: org/hibernate/annotations/common/reflection/ReflectionManager
O que significa:O NoClassDefFoundError indica a biblioteca Hibernate ausente.
Como resolver isto:Copie o
hibernate-annotations.jar
ehibernate-commons-annotations.jar
JARs a partir do diretórioEAP5_HOME/seam/lib/
ao diretóriojboss-seam-booking.ear/lib
.Reimplante o aplicativo apenas excluindo o arquivostandalone/deployments/jboss-seam-booking.ear.failed
e criando um arquivojboss-seam-booking.ear.dodeploy
vazio no mesmo diretório. - Os erros do período de execução e aplicativo devem ser resolvidos.Neste caso, o aplicativo implanta e executa sem erro.Clique na Seção 4.3.4, “Migração do Seam 2.2 Booking Archive ao JBoss EAP 6: Instruções de Etapa-por-Etapa” para retornar ao tópico anterior.
4.3.8. Revisão do Sumário das Alterações feitas quando Migrando o Aplicativo Seam 2.2 Booking
Importante
- Um arquivo
jboss-deployment-structure.xml
foi criado no diretórioMETA-INF/
do EAR. O<dependencies>
e<exclusions>
foram adicionados para resolver oClassNotFoundExceptions
. Este arquivo contém os seguintes dados:<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0"> <deployment> <dependencies> <module name="javax.faces.api" slot="1.2" export="true"/> <module name="com.sun.jsf-impl" slot="1.2" export="true"/> <module name="org.apache.commons.logging" export="true"/> <module name="org.dom4j" export="true"/> <module name="org.apache.commons.collections" export="true"/> </dependencies> </deployment> <sub-deployment name="jboss-seam-booking.war"> <exclusions> <module name="javax.faces.api" slot="main"/> <module name="com.sun.jsf-impl" slot="main"/> </exclusions> <dependencies> <module name="javax.faces.api" slot="1.2"/> <module name="com.sun.jsf-impl" slot="1.2"/> </dependencies> </sub-deployment> </jboss-deployment-structure>
- Os seguintes JARs foram copiados do diretório
EAP5_HOME/jboss-eap-5.X/seam/lib/
(substitua 5.X pela versão do EAP 5 que a migração está sendo efetuada) ao diretóriojboss-seam-booking.ear/lib/
para resolver oClassNotFoundExceptions
:- hibernate-core.jar
- hibernate-validator.jar
- O arquivo
jboss-seam-booking.jar/META-INF/persistence.xml
foi modificado conforme o seguinte.- O elemento
jta-data-source
foi alterado para uso do banco de dados da amostra que lança o JBoss EAP 6:<!-- <jta-data-source>java:/bookingDatasource</jta-data-source> --> <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
- A propriedade hibernate.cache.provider_class foi comentada:
<!-- <property name="hibernate.cache.provider_class" value="org.hibernate.cache.HashtableCacheProvider"/> -->
- O arquivo
lib/components.xml
do WAR foi modificado para uso de novos JNDI bindings- O elemento existente
core:init
foi substituído conforme abaixo:<!-- <core:init jndi-pattern="jboss-seam-booking/#{ejbName}/local" debug="true" distributable="false"/> --> <core:init jndi-pattern="java:app/jboss-seam-booking.jar/#{ejbName}" debug="true" distributable="false"/>
- Os elementos do componente para o "EjbSynchronizations" e "TimerServiceDispatcher" JNDI bindings foram adicionados:
<component class="org.jboss.seam.transaction.EjbSynchronizations" jndi-name="java:app/jboss-seam/EjbSynchronizations"/> <component class="org.jboss.seam.async.TimerServiceDispatcher" jndi-name="java:app/jboss-seam/TimerServiceDispatcher"/>
Apêndice A. Histórico de Revisão
Histórico de Revisões | |||
---|---|---|---|
Revisão 6.3.0-24 | Wednesday July 30 2014 | Sande Gilda | |
|