Capítulo 3. Migre seu Aplicativo
3.1. Alterações Requeridas para a maioria dos Aplicativos Copiar o linkLink copiado para a área de transferência!
3.1.1. Revisão das Alterações Requeridas para a Maioria dos Aplicativos Copiar o linkLink copiado para a área de transferência!
3.1.2. Alterações do Carregamento de Classe Copiar o linkLink copiado para a área de transferência!
3.1.2.1. Atualização do Aplicativo devido às Alterações do Carregamento da Classe Copiar o linkLink copiado para a área de transferência!
- Primeiro, busque pelo 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 não efetuar a conexão, você precisará especificar as dependências de módulo corretas. Consulte a Seção 3.1.4.1, “Modificação das Dependências de Registro em Log” para maiores informações
- Devido às alterações de carregamento de classe modular, você talvez precise alterar a estrutura do empacotamento de seu EAR ou WAR. 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 Copiar o linkLink copiado para a área de transferência!
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 implicitamente automatizado, adicionam algumas das dependências do módulo comumente usadas, como por exemplojavax.apiesun.jdk. Isto faz as classes visíveis à implantação no período de execução e libera o desenvolvedor da tarefa de adicionar explicitamente as dependências. Para maiores detalhes de como e quando essas dependências implícitas são adicionadas, refira-se às Dependências de Módulo Implícitas no capítulo nomeado Carregamento de Classe e Módulos do Guia de Desenvolvimento do JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.Compreendendo as dependências explícitas
Para outras classes, os módulos devem ser especificados explicitamente ou as dependências ausentes resultam em erros de implantação ou do período de execução. Caso falte uma dependência, você verá traçosClassNotFoundExceptionsouNoClassDefFoundErrorsno log do servidor. Caso mais de um módulo efetuar o carregamento ao mesmo JAR ou um módulo efetuar o carregamento numa classe que estende a classe com carregamento por um módulo diferente, você verá traçosClassCastExceptionsno log do servidor. Para especificar as dependências, modifique oMANIFEST.MFou crie umjboss-deployment-structure.xmldo arquivo do descritor de implantação específico do JBoss. Para maiores informações sobre as dependências do módulo, refira-se à Visão Geral de Carregamento de Classe e Módulo no capítulo chamado Carregamento de Classe e Módulo no Guia de Desenvolvimento do 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 Copiar o linkLink copiado para a área de transferência!
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, o 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 nomeado Carregamento de Classe e Módulos no 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 Copiar o linkLink copiado para a área de transferência!
3.1.3.1. Criação ou Modificação dos Arquivos que controlam o Controle de Carregamento da Classe no JBoss EAP 6 Copiar o linkLink copiado para a área de transferência!
Devido à alteração no JBoss EAP 6 para uso do carregamento da classe modular, você talvez precise criar ou modificar um ou mais arquivos para adicionar dependências ou para prevenir dependências automáticas de serem carregadas. Para maiores informações sobre o carregamento de classe e a procedência do carregamento de classe, refira-se 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/.
- jboss-web.xml
- Caso tenha definido um elemento
<class-loading>no arquivojboss-web.xml, você precisará removê-lo. O comportamento que isto causou no JBoss EAP 5 é agora o comportamento do carregamento da classe default no JBoss EAP 6, portanto não é mais necessário. Caso você não remova mais esse elemento, você verá um ParseError e XMLStreamException no seu log do servidor.Segue abaixo uma amostra do elemento<class-loading>no arquivojboss-web.xmlque encontra-se comentado.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - MANIFEST.MF
- Editado manualmente
- Dependendo de quais componentes ou módulos o seu aplicativo usa, você precisa adicionar uma ou mais dependências a este arquivo. Você pode adicioná-las tanto como
Dependenciesou como entradasClass-Path.Segue abaixo uma amostraMANIFEST.MFeditada por um desenvolvedor:Manifest-Version: 1.0 Dependencies: org.jboss.logmanager Class-Path: OrderManagerEJB.jar
Manifest-Version: 1.0 Dependencies: org.jboss.logmanager Class-Path: OrderManagerEJB.jarCopy to Clipboard Copied! Toggle word wrap Toggle overflow Caso você modifique esse arquivo, certifique-se de incluir um caractere com linha nova no final do arquivo. - Usando o Maven
- Caso você use o Maven, você precisa modificar o seu arquivo
pom.xmlpara gerar as dependências para o arquivoMANIFEST.MF. Caso seu aplicativo usar o EJB 3.0, você pode possuir uma seção no arquivopom.xmlparecida com o seguinte:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Caso o código EJB 3.0 usar oorg.apache.commons.log, você precisará daquela dependência no arquivoMANIFEST.MF. Com o objetivo de gerar aquela dependência, adicione o elemento<plugin>ao arquivopom.xml, conforme abaixo:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Na amostra acima, o arquivosrc/main/resources/META-INF/MANIFEST.MFprecisa apenas conter a entrada da dependência:Dependencies: org.apache.commons.logging
Dependencies: org.apache.commons.loggingCopy to Clipboard Copied! Toggle word wrap Toggle overflow O Maven gerará o arquivoMANIFEST.MFcompleto:Manifest-Version: 1.0 Dependencies: org.apache.commons.logging
Manifest-Version: 1.0 Dependencies: org.apache.commons.loggingCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- 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.xmlque adiciona uma dependência para o módulo JSF 1.2 e previne o carregamento automático do módulo JSF 2.0.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Consulte a Seção 3.1.3.2, “jboss-deployment-structure.xml” para informações adicionais sobre este arquivo. - application.xml
- Nas versões anteriores do JBoss EAP, você controlou a ordem das implantações com um EAR usando o arquivo
jboss-app.xml. Isto não é mais a mesma situação. O Java EE6 spec fornece o elemento<initialize-in-order>noapplication.xmlque permite o controle da ordem pela qual os módulos do Java EE com um EAR são implantados.Na maioria das vezes, você não precisa 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 que você possui um aplicativo que contém ummyBeans.jare ummyApp.warcom ummyApp.ear. Um servlet nomyApp.war@EJBinjeta um bean domyBeans.jar. Neste caso, o servidor do aplicativo possui um conhecimento apropriado para certificar-se de que o componente EJB está disponível antes do servlet ser iniciado e você não precisará usar o elemento<initialize-in-order>.No entanto, caso o servlet usar referências remotas de estilo de pesquisa JNDI de legacia como o seguinte para acesso ao bean, você poderá especificar a ordem do módulo.Neste caso, o servidor não está apto a determinar que o componente EJB está noinit() { Context ctx = new InitialContext(); ctx.lookup("TheBeanInMyBeansModule"); }init() { Context ctx = new InitialContext(); ctx.lookup("TheBeanInMyBeansModule"); }Copy to Clipboard Copied! Toggle word wrap Toggle overflow myBeans.jare você precisa reforçar que os componentes nomyBeans.jarsão inicializados e ativados antes dos componentes nomyApp.war. Para isto, você configura o elemento<initialize-in-order>paratruee especifica a ordem dos módulosmyBeans.jaremyApp.warno 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.Copy to Clipboard Copied! Toggle word wrap Toggle overflow O esquema para o arquivoapplication.xmlpode ser encontrado no http://java.sun.com/xml/ns/javaee/application_6.xsd.Nota
Você deve estar ciente que a configuração do elemento<initialize-in-order>paratruereduz 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.xmlsubstitui o descritor da implantaçãojboss.xmlpara 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.xmle ojboss.xmlé agora ignorado nas implantações. - login-config.xml
- O arquivo
login-config.xmlnã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 você esteja executando o seu servidor num managed domain, esse é o arquivodomain/configuration/domain.xml.
3.1.3.2. jboss-deployment-structure.xml Copiar o linkLink copiado para a área de transferência!
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 Copiar o linkLink copiado para a área de transferência!
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, você deve empacotar os arquivos de propriedades, JARs e outros artefatos com WAR, movendo-os ao diretório
WEB-INF/classes/ouWEB-INF/lib/. Essa abordagem está descrita com 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 você deseje disponibilizar recursos personalizados a todos os aplicativos executando no servidor do JBoss EAP 6, você deve criar 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 Copiar o linkLink copiado para a área de transferência!
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, você deve empacotá-las com seu aplicativo.
Procedimento 3.2.
- Caso esteja implantando um arquivo WAR, você deve empacotar essas propriedades na pasta
WEB-INF/classes/do WAR. - Caso deseje disponibilizar essas propriedades a todos os componentes num EAR, você deve empacotá-las à raiz do JAR na pasta
lib/do EAR.
3.1.3.5. Criação de um Módulo Personalizado Copiar o linkLink copiado para a área de transferência!
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/modulepara conter os arquivos e JARs. Por exemplo:cd EAP_HOME/modules/ $ mkdir -p myorg-conf/main/properties
$ cd EAP_HOME/modules/ $ mkdir -p myorg-conf/main/propertiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Mova os arquivos de propriedades ao diretório
EAP_HOME/modules/myorg-conf/main/properties/criado na etapa anterior. - Crie um arquivo
module.xmlno diretórioEAP_HOME/modules/myorg-conf/main/contendo o seguinte XML:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- Modifique o subsistema
eeno 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
$ EAP_HOME/bin/jboss-cli.sh --connectCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Insira a seguinte linha de comando para o Windows:
C:\>EAP_HOME\bin\jboss-cli.bat --connect
C:\>EAP_HOME\bin\jboss-cli.bat --connectCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Você deverá observar a seguinte resposta:Conectado ao controlador autônomo no localhost:9999
Conectado ao controlador autônomo no localhost:9999Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Para criar o elemento
myorg-conf<global-modules> no subsistemaee, digite o seguinte na linha de comando:/subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])/subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])Copy to Clipboard Copied! Toggle word wrap Toggle overflow Você deverá ver o seguinte resultado:{"outcome" => "success"}{"outcome" => "success"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 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 você esteja executando um servidor autônomo, este é o arquivo
EAP_HOME/standalone/configuration/standalone.xmlou caso esteja executando um managed domain, o arquivo é oEAP_HOME/domain/configuration/domain.xml. - Encontre o subsistema
eee adicione o módulo global paramyorg-conf. Segue abaixo uma amostra do elemento do subsistemaeemodificado para inclusão do elementomyorg-conf:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 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");Thread.currentThread().getContextClassLoader().getResource("my.properties");Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.4. Alterações do Registro em Log Copiar o linkLink copiado para a área de transferência!
3.1.4.1. Modificação das Dependências de Registro em Log Copiar o linkLink copiado para a área de transferência!
O JBoss LogManager suporta front ends para todos os frameworks de registro em log, de forma que você pode 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, você precisará provavelmente modificar seu aplicativo para adicionar as 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 Copiar o linkLink copiado para a área de transferência!
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. No entanto, caso você esteja usando o log4j e você não deseja usar o subsistema de registro em log para configurar seus manuseadores (anexadores), você precisa excluir o módulo do log4j do JBoss EAP 6.
Procedimento 3.5. Configuração do JBoss EAP 6 para uso de um arquivo log4j.properties ou log4j.xml
- Criação de um
jboss-deployment-structure.xmlcom o seguinte conteúdo:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Posicione o arquivo
jboss-deployment-structure.xmltanto no diretórioMETA-INF/ou diretórioWEB-INF/, caso esteja implantando um WAR ou no diretórioMETA-INF/, caso você esteja implantando um EAR. - Adicione o arquivo
log4j.propertiesoulog4j.xmlno diretóriolib/de seu EAR ou no diretórioWEB-INF/classes/de sua implantação WAR. - Implante seu aplicativo.
Nota
3.1.4.3. Modificação do Código para Uso do Novo Framework de Registro de Log do JBoss Copiar o linkLink copiado para a área de transferência!
Para usar o novo framework, altere suas importações e código conforme abaixo:
Procedimento 3.6. 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:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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-MFdeve parecer com o seguinte:Manifest-Version: 1.0 Dependencies: org.jboss.logging
Manifest-Version: 1.0 Dependencies: org.jboss.loggingCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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 Copiar o linkLink copiado para a área de transferência!
3.1.5.1. Modificação do Empacotamento dos EARS e WARs Copiar o linkLink copiado para a área de transferência!
Quando você migrar seu aplicativo, é possível que você tenha que alterar a 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.7. 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 sub-implantaçã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 sub-implantaçõ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 sub-implantaçõ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>
<subsystem xmlns="urn:jboss:domain:ee:1.0" > <ear-subdeployments-isolated>false</ear-subdeployments-isolated> </subsystem>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Por default, isto é configurado para falso, permitindo que as sub-implantações vejam as classes pertencentes às demais sub-implantações com o EAR.Para maiores informações sobre o carregamento da classe, refira-se ao capítulo 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 Copiar o linkLink copiado para a área de transferência!
3.1.6.1. Atualização do Aplicativo devido às Alterações da Configuração Copiar o linkLink copiado para a área de transferência!
- Caso o seu aplicativo usar uma fonte de dados, consulte a Seção 3.1.6.2, “Atualização da Configuração da Fonte de Dados”.
- Caso o seu aplicativo usar JPA e empacotar o Hibernate JARs, consulte as opções de migração na Seção 3.1.6.4, “Configuração da Fonte de Dados para o Hibernate ou JPA”.
- Caso o seu aplicativo usar um adaptador de recurso, consulte a Seção 3.1.6.5, “Atualização da Configuração do Adaptador de Recurso”.
- Revise abaixo as informações de como configurar as alterações para 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 Copiar o linkLink copiado para a área de transferência!
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 (Management Console da Web) e a interface da linha de comando (CLI). 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 core. 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 que é gerenciável pelo Management Console da Web e 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: 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 Copiar o linkLink copiado para a área de transferência!
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.8. Instalação e Configuração do JDBC Driver
Instalação do JBBC Driver
Instale o JDBC Driver como uma implantação
Esta é a maneira recomendada para instalar o 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 ao JAR no diretórioEAP_HOME/standalone/deployments/. Caso o servidor estiver sendo executado num managed domain, copie o JAR ao diretórioEAP_HOME/domain/deployments/.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/
$cp mysql-connector-java-5.1.15.jar EAP_HOME/standalone/deployments/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.Driverque 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.Driverao JAR sob o caminhoMETA-INF/services/. Esse arquivo deve conter o nome de classe do driver, por exemplo:com.mysql.jdbc.Driver
com.mysql.jdbc.DriverCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Crie um arquivo
java.sql.Driverno diretório de implantação. Para uma instância do JBoss EAP 6 sendo executada como servidor autônomo, o arquivo deve ser posicionado aqui:EAP_HOME/standalone/deployments/META-INF/services/java.sql.Driver. Caso o servidor estiver num managed domain, o arquivo deve ser posicionado aqui:EAP_HOME/domain/deployments/META-INF/services/java.sql.Driver.
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 um JAR com licença independente ou JAR de localização, você não pode instalar o driver como uma implantação. Você deve instalar o JDBC driver 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 módulo core
Para instalar um JDBC driver como um módulo core, você deve criar uma estrutura do caminho do arquivo sob o diretórioEAP_HOME/modules/. Esta estrutura contém o JDBC driver JAR, qualquer licença do fornecedor adicional ou JARs de localização e um arquivomodule.xmlpara definir o 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.xmlcontendo a seguinte definição do módulo para o MySQL JDBC driver:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 você NÃO possui espaço no início do arquivomodule.xmlou você obterá um erro "New missing/unsatisfied dependencies" para este driver. - 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/
$ cp mysql-connector-java-5.1.15.jar EAP_HOME/modules/com/mysql/main/Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Instale o IBM DB2 JDBC driver e licença JAR 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.xmlcontendo a seguinte definição do módulo para o IBM DB2 JDBC driver e licença:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Nota
Certifique-se de que você NÃO possui espaço no início do arquivomodule.xmlou você obterá um erro "New missing/unsatisfied dependencies" para este driver. - 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.jar EAP_HOME/modules/com/ibm/db2/main/
$ cp db2jcc.jar EAP_HOME/modules/com/ibm/db2/main/ $ cp db2jcc_license_cisuz.jar EAP_HOME/modules/com/ibm/db2/main/Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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.
Configuração da fonte de dados
Adição do 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.Driverque 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:Um driver que não seja compatível com o JDBC 4.0 requer um atributo<driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"/>
<driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"/>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <driver-class>para identificar a classe do driver desde que não haja um arquivoMETA-INF/services/java.sql.Driverque 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>
<driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"><driver-class>com.mysql.jdbc.Driver</driver-class></driver>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Criação da 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
Você deve interromper o servidor antes de editar o arquivo de configuração do servidor para que sua alteração seja persistida na iniciação do servidor.Segue abaixo uma amostra de um elemento de fonte de dados MySQL no arquivostandalone.xml:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.6.4. Configuração da Fonte de Dados para o Hibernate ou JPA Copiar o linkLink copiado para a área de transferência!
Caso o seu aplicativo usar o JPA e empacotar atualmente JBoss JARs, você deverá usar o Hibernate que está incluso com o JBoss EAP 6. Para uso dessa versão do Hibernate, você deve remover o pacote antigo do Hibernate de seu aplicativo.
Procedimento 3.9. 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.xmluma vez que este elemento não é necessário.
3.1.6.5. Atualização da Configuração do Adaptador de Recurso Copiar o linkLink copiado para a área de transferência!
Nas versões anteriores do servidor do aplicativo, a configuração do adaptador do recurso era definido num arquivo com um sufixo *-ds.xml. No JBoss EAP 6, o adaptador de recurso é configurado no arquivo de configuração do servidor. Caso você esteja executando num managed domain, o arquivo de configuração é o arquivo EAP_HOME/domain/configuration/domain.xml. Caso você esteja executando como um 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 no Resource adapter descriptors.
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"/>
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1"/>
*-ds.xml do adaptador de recurso.
3.1.7. Alterações de Segurança Copiar o linkLink copiado para a área de transferência!
3.1.7.1. Configuração das Alterações de Segurança do Aplicativo Copiar o linkLink copiado para a área de transferência!
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:
${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.
- Você deve remover esse prefixo das configurações do security domain para os aplicativos da Web no
jboss-web.xml. - Você deve remover esse prefixo das configurações do security domain para os aplicativos Enterprise no
jboss-web.xml. Esse arquivo foi substituído pelojboss.xmlno JBoss EAP 6.
3.1.8. Alterações JNDI Copiar o linkLink copiado para a área de transferência!
3.1.8.1. Atualização dos Nomes JNDI Namespace do Aplicativo Copiar o linkLink copiado para a área de transferência!
O EJB 3.1 introduzido a um JNDI namespace glogal padronizado e uma série de namespaces relacionados que mapeiam várious 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.10. 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 Copiar o linkLink copiado para a área de transferência!
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.
| 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 ao 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 teria acesso 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 Copiar o linkLink copiado para a área de transferência!
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
DefaultDSoujdbc/DefaultDSdevem ser relativamente qualificados para ojava:comp/env,java:module/envoujava:jboss/env, dependendo do contexto. - Os nomes
absolutenão qualificados como/jdbc/DefaultDSdevem ser relativamente qualificados a um nomejava:jboss/root. - Os nomes
absolutequalificados como ojava:/jdbc/DefaultDSdevem ser qualificados da mesma forma que os nomesabsolutenão qualificados acima. - O espaço do nome
java:jbossespecial é compartilhado por toda a instância do servidor AS. - Qualquer nome
relativecom o prefixojava:deve estar em um dos cinco espaços do nome:comp,module,app,globaloujbossproprietário. Qualquer nome começando comjava:xxxonde xxx não combina com nenhum dos cinco acima e resultaria num erro de nome inválido.
3.1.8.4. Modificação do Aplicativo para Seguir as Novas Regras do JNDI Namespace (Espaço do Nome JNDI) Copiar o linkLink copiado para a área de transferência!
- Segue abaixo uma amostra da pesquisa JNDI no JBoss EAP 5.1. Este código é normalmente encontrado num método de inicialização.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note que o nome de pesquisa éOrderManagerApp/ProductManagerBean/local. - Segue abaixo uma amostra de como a mesma pesquisa seria codificada no JBoss EAP 6 usando o CDI.
@EJB(lookup="java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager") private ProductManager productManager;
@EJB(lookup="java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager") private ProductManager productManager;Copy to Clipboard Copied! Toggle word wrap Toggle overflow Os valores de pesquisa são definidos como variáveis do associado e usam o novo nomejava:appJNDI namespacejava:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager. - Caso você prefira não usar o CDI, você pode continuar a criar um novo InitialContext conforme acima e modificar a pesquisa para uso do novo nome JNDI namespace.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.8.5. Amostra do JNDI Namespaces nos Lançamentos Anteriores e como são especificados no JBoss EAP 6 Copiar o linkLink copiado para a área de transferência!
| 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 |