Guia de Migração

1. 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.

2. 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
3. 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.

Procedimento 3.1. Compreendendo as Dependências do Módulo

1. 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 exemplo javax.api e sun.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/.

2. 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ços ClassNotFoundExceptions ou NoClassDefFoundErrors no 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ços ClassCastExceptions no log do servidor. Para especificar as dependências, modifique o MANIFEST.MF ou crie um jboss-deployment-structure.xml do 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/.

Procedimento 3.2. 

1. Caso esteja implantando um arquivo WAR, você deve empacotar essas propriedades na pasta WEB-INF/classes/ do WAR.

2. Caso deseje disponibilizar essas propriedades a todos os componentes num EAR, você deve empacotá-las à raiz do JAR na pasta lib/ do EAR.

Procedimento 3.3. Criação de um Módulo Personalizado

1. Crie e preencha a estrutura do diretório module/.
   1. 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
      
      

      Copy to Clipboard Toggle word wrap
   2. Mova os arquivos de propriedades ao diretório EAP_HOME/modules/myorg-conf/main/properties/ criado na etapa anterior.
   3. Crie um arquivo module.xml no diretório EAP_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>
      
      

      Copy to Clipboard Toggle word wrap
2. 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.
     1. 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
          

          Copy to Clipboard Toggle word wrap
        • Insira a seguinte linha de comando para o Windows:

          C:\>EAP_HOME\bin\jboss-cli.bat --connect
          

          Copy to Clipboard Toggle word wrap
        Você deverá observar a seguinte resposta:

        Conectado ao controlador autônomo no localhost:9999

        Copy to Clipboard Toggle word wrap
     2. Para criar o elemento myorg-conf<global-modules> no subsistema ee, digite o seguinte na linha de comando:

        /subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])
        

        Copy to Clipboard Toggle word wrap
        Você deverá ver o seguinte resultado:

        {"outcome" => "success"}
        

        Copy to Clipboard Toggle word wrap
   • Siga essas etapas caso prefira editar manualmente o arquivo da configuração do servidor.
     1. 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.xml ou caso esteja executando um managed domain, o arquivo é o EAP_HOME/domain/configuration/domain.xml.
     2. Encontre o subsistema ee e adicione o módulo global para myorg-conf. Segue abaixo uma amostra do elemento do subsistema ee modificado para inclusão do elemento myorg-conf:

        <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
            <global-modules>
                <module name="myorg-conf" slot="main" />            
            </global-modules>
        </subsystem>
        
        

        Copy to Clipboard Toggle word wrap
3. 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");
   

   Copy to Clipboard Toggle word wrap

Procedimento 3.4. Atualização do código de registro de log do aplicativo

1. Seção 3.1.4.2, “Atualização do Código do Aplicativo para Frameworks de Registro de Log de Terceiros”
2. Seção 3.1.4.3, “Modificação do Código para Uso do Novo Framework de Registro de Log do JBoss”

Procedimento 3.5. Configuração do JBoss EAP 6 para uso de um arquivo log4j.properties ou log4j.xml

1. 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>
   
   

   Copy to Clipboard Toggle word wrap
2. Posicione o arquivo jboss-deployment-structure.xml tanto no diretório META-INF/ ou diretório WEB-INF/, caso esteja implantando um WAR ou no diretório META-INF/, caso você esteja implantando um EAR.
3. Adicione o arquivo log4j.properties ou log4j.xml no diretório lib/ de seu EAR ou no diretório WEB-INF/classes/ de sua implantação WAR.
4. Implante seu aplicativo.

Procedimento 3.6. Modifique o Código e Dependências para Uso do JBoss logging Framework

1. 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);
   }
   

   Copy to Clipboard Toggle word wrap

2. Adição de dependência de registro em log

   O JAR contendo as classes do JBoss Logging está localizado no módulo nomeado org.jboss.logging. O seu arquivo MANIFEST-MF deve parecer com o seguinte:

   Manifest-Version: 1.0
   Dependencies: org.jboss.logging
   

   Copy to Clipboard Toggle word wrap
   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.

Procedimento 3.7. Modificação do empacotamento do arquivo

1. 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ório WEB-INF/lib/ são tratadas da mesma forma que as classes no diretório WEB-INF/classes.

2. Empacotamento de um EAR

   Um EAR consiste de módulos múltiplos. O diretório EAR/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ório EAR/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 subsistema ee, conforme abaixo:

   <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
     <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
   </subsystem>
   

   Copy to Clipboard Toggle word wrap
   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/.

1. 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”.

2. 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”.
3. 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”.
4. 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”.

Procedimento 3.8. Instalação e Configuração do JDBC Driver

1. Instalação do JBBC Driver

   1. 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ório EAP_HOME/standalone/deployments/. Caso o servidor estiver sendo executado num managed domain, copie o JAR ao diretório EAP_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/

      Copy to Clipboard Toggle word wrap
      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 nomeado META-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 caminho META-INF/services/. Esse arquivo deve conter o nome de classe do driver, por exemplo:

        com.mysql.jdbc.Driver

        Copy to Clipboard Toggle word wrap
      • Crie um arquivo java.sql.Driver no 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:

      • 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.

      Os aspectos negativos desta abordagem são:

      • 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/.

   2. 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ório EAP_HOME/modules/. Esta estrutura contém o JDBC driver JAR, qualquer licença do fornecedor adicional ou JARs de localização e um arquivo module.xml para definir o módulo.

      • Instale o MySQL JDBC Driver como módulo core

        1. Crie uma estrutura de diretório EAP_HOME/modules/com/mysql/main/
        2. No subdiretório main/, crie um arquivo module.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>
           
           
           

           Copy to Clipboard Toggle word wrap
           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 nomeado javax.api. Este módulo está localizado sob o diretório modules/system/layers/base/javax/api/main/.

           Nota

           Certifique-se de que você NÃO possui espaço no início do arquivo module.xml ou você obterá um erro "New missing/unsatisfied dependencies" para este driver.
        3. 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/

           Copy to Clipboard Toggle word wrap

      • 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.
        1. Crie a estrutura do diretório EAP_HOME/modules/com/ibm/db2/main/.
        2. No subdiretório main/ crie um arquivo module.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>
           
           

           Copy to Clipboard Toggle word wrap

           Nota

           Certifique-se de que você NÃO possui espaço no início do arquivo module.xml ou você obterá um erro "New missing/unsatisfied dependencies" para este driver.
        3. 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/

           Copy to Clipboard Toggle word wrap
      Os aspectos positivos 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.

      Os aspectos negativos desta abordagem são:

      • É mais difícil configurar um módulo.
      • O módulo deve ser manualmente copiado para cada servidor executando num managed domain.

2. Configuração da fonte de dados

   1. 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 arquivo META-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"/>
      

      Copy to Clipboard Toggle word wrap

      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 arquivo META-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>
      
      

      Copy to Clipboard Toggle word wrap

   2. Criação da fonte de dados

      Crie um elemento <datasource> na seção <datasources> do arquivo standalone.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 arquivo standalone.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>
      
      

      Copy to Clipboard Toggle word wrap

Procedimento 3.9. Remoção do pacote Hibernate

1. Remova o Hibernate JARs de suas pastas da biblioteca do aplicativo.

2. Remova ou comente o elemento <hibernate.transaction.manager_lookup_class> em seu arquivo persistence.xml uma vez que este elemento não é necessário.

Procedimento 3.10. Modificação das pesquisas JNDI

1. Leia mais a respeito deste assunto na Seção 3.1.8.2, “Nomes do EJB JNDI Portátil ”

2. Seção 3.1.8.3, “Revisão das Regras JNDI Namespace”
3. Seção 3.1.8.4, “Modificação do Aplicativo para Seguir as Novas Regras do JNDI Namespace (Espaço do Nome JNDI)”

Procedimento 3.11. 

1. Seção 3.2.2.2, “Configuração das Alterações para Aplicativos que usam o Hibernate e o JPA”

2. Seção 3.2.2.4, “Atualização de seu Aplicativo Hibernate 3 para uso do Hibernate 4”

3. Seção 3.2.2.9, “Atualização de seu Aplicativo para ficar de acordo com a Especificação JPA 2.0”

4. Seção 3.2.2.10, “Substituição do Cache de Segundo Nível JPA/Hibernate com o Infinispan”

5. Seção 3.2.2.12, “Migração para o Validador Hibernate 4”

Procedimento 3.12. Configuração do Aplicativo

1. 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ório lib/ do aplicativo ou adicionando-as ao classpath usando algum outro método. Em alguns casos, isto pode resultar no ClassCastExceptions 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.

2. 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 o jboss.as.jpa.providerModule para hibernate3-bundled no persistence.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>
   
   

   Copy to Clipboard Toggle word wrap

   O implantador do Java Persistence API (JPA - API de Persistência Java) detectará a presença de um provedor de persistência no aplicativo e uso das bibliotecas do Hibernate 3. Consulte a Seção 3.2.2.3, “Propriedades da Unidade de Persistência” para maiores informações sobre as propriedades de persistência JPA.

3. 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> para false no arquivo persistence.xml.

Procedimento 3.13. Atualização do aplicativo para uso do Hibernate 4

1. O comportamento default gerador da sequência de auto-incremento 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.
2. Determine a versão do Hibernate sendo utilizado pelo aplicativo e escolha o procedimento de atualização correto abaixo.
   • Seção 3.2.2.6, “Migração de seu Aplicativo Hibernate 3.3.x para o Hibernate 4.x ”
   • Seção 3.2.2.7, “Migração de seu Aplicativo Hibernate 3.5.x para o Hibernate 4.x”
3. Consulte a Seção 3.2.2.8, “Modificação das Propriedades de Persistência para o Seam Migrado” caso deseje executar seu aplicativo num ambiente com cluster.

Procedimento 3.14. 

1. Mapeie os tipos de text Hibernate para JDBC LONGVARCHAR

   Nas versões anteriores do Hibernate 3.5, o tipo de text era mapeado para JDBC CLOB. Um novo tipo de Hibernate, materialized_clob, foi adicionado ao Hibernate 4 para mapear as propriedades Java String para JDBC CLOB. Caso o seu aplicativo possuir propriedades configuradas como type="text" que possuem por intenção serem mapeadas para JDBC CLOB, você deve fazer o seguinte:
   1. Caso o seu aplicativo usar arquivos de mapeamento hbm, altere a propriedade para type="materialized_clob".
   2. Caso seu aplicativo usar anotações, você deve substituir @Type(type = "text") por @Lob.

2. 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 no org.hibernate.criterion foram alteradas.
   1. Devido às alterações no CountProjection, Projections.rowCount(), Projections.count(propertyName) e Projections.countDistinct(propertyName), as projeções count e count distinct retornam agora um valor Long.
   2. Devido às alterações no Projections.sum(propertyName), as projeções sum retornam agora um tipo de valor que depende do tipo de propriedade.

      Nota

      Falha ao modificar o seu código do aplicativo num java.lang.ClassCastException.
      1. Para propriedades mapeadas com tipos de número primitivo, Número, Longo ou Curto, o valor Longo é retornado;
      2. Para propriedades mapeadas como tipos de ponto flutuante primitivo, Duplo ou Flutuante, o valor Duplo é retornado.

Procedimento 3.15. 

1. Mescle o AnnotationConfiguration na Configuração

   Embora o AnnotationConfiguration tenha sido substituído, ele não deve afetar a sua migração.
   Caso você esteja usando um arquivo hbm.xml, você deve estar ciente que o JBoss EAP 6 usa o org.hibernate.cfg.EJB3NamingStrategy no AnnotationConfiguration ao invés do org.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 o org.hibernate.cfg.DefaultNamingStrategy de legacia chamando o Configuration#setNamingStrategy e passando-o ao org.hibernate.cfg.DefaultNamingStrategy#INSTANCE.

2. Modifique os namespaces para estarem de acordo com os novos arquivos Hibernate DTD.

   Expand

   Tabela 3.5.

   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

   Show more

3. Modifique as variáveis do ambiente

   1. Caso você esteja usando o Oracle e usando as propriedades materialized_clob ou materialized_blob, a variável de ambiente global hibernate.jdbc.use_streams_for_binary deve ser configurada para verdadeiro.
   2. Caso você esteja usando o PostgreSQL e usando as propriedades CLOB ou BLOB, o hibernate.jdbc.use_streams_for_binary da variável do ambiente global deve ser configurado para falso.

Procedimento 3.16. Configuração das propriedades a serem executadas num ambiente com cluster

1. 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 EAP 6. Por exemplo:

   <property name="hibernate.session_factory_name" value="jboss-seam-booking.ear_session_factory"/>
   
   

   Copy to Clipboard Toggle word wrap
2. Determine p 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"/>
   
   

   Copy to Clipboard Toggle word wrap

Procedimento 3.17. Modificação do arquivo persistence.xml para uso Infinispan

1. 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"/>
   
   

   Copy to Clipboard Toggle word wrap

   Além disso, você precisa especificar um shared-cache-mode com um valor de ENABLE_SELECTIVE ou ALL 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>
     
     

     Copy to Clipboard Toggle word wrap
   • ALL significa que as entidades sempre possuem cache mesmo que você as marque sem cache.

     <shared-cache-mode>ALL</shared-cache-mode>
     
     

     Copy to Clipboard Toggle word wrap

2. 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"/>
   
   
   

   Copy to Clipboard Toggle word wrap

   Você deve adicionar o seguinte ao arquivo MANIFEST.MF:

   Manifest-Version: 1.0
   Dependencies: org.infinispan, org.hibernate
   

   Copy to Clipboard Toggle word wrap

Procedimento 3.18. Você pode precisar executar uma ou mais dessas tarefas

1. Acesso ao ValidatorFactory default

   O JBoss EAP 6 bind (associa) o ValidatorFactory default ao contexto JNDI sob o nome java:comp/ValidatorFactory.

2. Compreendendo o 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.

   1. A validação ocorre nas operações INSERT, UPDATE e DELETE de entidade.

   2. Você pode configurar os grupos a serem validados pelo tipo de evento usando as seguintes propriedades:

      • javax.persistence.validation.group.pre-persist,
      • javax.persistence.validation.group.pre-update, and
      • javax.persistence.validation.group.pre-remove.

      Os valores dessas propriedades são de vírgula separada, nomes de classe inteiramente qualificada dos grupos a serem validados.
      Os grupos de validação são um novo recurso da especificação da Validação Bean. Caso você não deseje aproveitar as vantagens desse novo recurso, não existem alterações requeridas na migração para o Hibernate Validator 4.
   3. Caso você desativar o ciclo de vida baseado na validação pela configuração da propriedade javax.persistence.validation.mode para none. Outros valores válidos para esta propriedade são auto (o default), callback e ddl.

3. Configuração de seu aplicativo para uso da validação

   1. Caso você deseje manualmente controlar a validação, você pode criar um Validador em algumas das seguintes maneiras:

      • Crie uma instância Validator a partir do ValidatorFactory usando o método getValidator().
      • Injete as Instâncias do Validador em seu EJB. O bean CDI ou qualquer outro recurso injetável do Java EE.
   2. Você pode usar o ValidatorContext retornado pelo ValidatorFactory.usingContext() para personalizar sua instância do Validador. Você pode configurar um MessageInterpolator, TraverableResolver e ConstraintValidatorFactory personalizado usando o API. Essas interfaces são específicas na especificação do Bean Validation e são novas ao Hibernate Validator 4.

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.

   1. Você deve usar as restrições nos seguintes pacotes para atualização ao Validador Hibernate 4:

      • javax.validation.constraints
      • org.hibernate.validator.constraints
   2. Todas as restrições que existiam no Hibernate Validator 3 continuam disponíveis no Hibernate Validator 4. Para usá-las, você precisa importar a classe especificada e em alguns casos alterar o nome ou tipo de parâmetro de restrição.

5. Uso de restrição personalizada

   No Hibernate Validator 3, é necessária uma restrição personalizada para implantar a interface org.hibernate.validator.Validator. No Hibernate Validator 4, você precisa implantar a interface javax.validation.ConstraintValidator. Essa interface contém os mesmos métodos initialize() e isValid() da interface anterior, no entanto, o método de assinatura foi alterado. Além disso, a alteração DDL não é mais suportada no Hibernate Validator 4.

Procedimento 3.19. Configure o JMS Bridge implantado a Servidor JBoss EAP 5.x

1. Crie um subdiretório no diretório de implantação do JBoss EAP 5 para conter o SAR, por exemplo: EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar
2. Crie um subdiretório nomeado META-INF no EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/.
3. Crie um arquivo jboss-service.xml que contém informação similar ao seguinte no diretório EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/META-INF/.

   <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>
           
   
   

   Copy to Clipboard Toggle word wrap

   Nota

   O <load-repository> está presente para garantir que o SAR já foi um classloader isolado. Além disso, perceba que ambos bridge "target" e bridge look-up incluem credenciais de segurança para o usuário "jbossuser" com senha "jbosspass". Isto é devido ao JBoss EAP 6 possuir segurança por default. O usuário nomeado "jbossuser" com senha "jbosspass" foi criado no ApplicationRealm com a função guest usando o script EAP_HOME/bin/add_user.sh.
4. Copie os seguintes JARs a partir do diretório EAP_HOME/modules/system/layers/base/ no diretório EAP5_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 o EAP_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.

Procedimento 3.20. Configure o JMS Bridge implantado a Servidor JBoss EAP 6.x

1. Criação do módulo do JBoss para o provedor de mensagem.
   1. Crie uma estrutura de diretório sob o EAP_HOME/modules/system/layers/base/ para o novo módulo. Osubdiretório main/ conterá o cliente JARs e o arquivo module.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/
   2. No subdiretório main/, crie um arquivo module.xml contendo a definição do módulo para o provedor de mensagem. Segue abaixo uma amostra do module.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>
      
      

      Copy to Clipboard Toggle word wrap
   3. Copie os JARs do provedor de mensagem requeridos pela pesquisa JNDI dos recursos de fonte ao subdiretório main/. A estrutura do diretório para o módulo MyCustomMQ deve parecer-se agora com o seguinte:

      modules/
      `-- system
          `-- layers
              `-- base
                  `-- org
                        `-- mycustommq
                            `-- main
                                |-- mycustommq-1.2.3.jar
                                |-- mylogapi-0.0.1.jar
                                |-- module.xml
      

      Copy to Clipboard Toggle word wrap
2. Configure o JMS bridge no subsistema messaging do servidor do JBoss EAP 6.
   1. 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 arquivos EAP_HOME/domain/configuration/domain.xml e EAP_HOME/domain/configuration/host.xml.
   2. Adicione o elemento <jms-bridge> ao subsistema messaging no arquivo de configuração do servidor. Os elementos <source> e <target> fornecem os nomes dos recursos JMS usados para as pesquisas JNDI. Caso os credenciais <user> e <password> forem especificados, eles serão passados como argumentos quando a conexão for criada.
      Segue abaixo uma amostra do elemento <jms-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>
      
      

      Copy to Clipboard Toggle word wrap

      Na amostra acima, as propriedades JNDI são definidas no elemento <context> para o <source>. Caso o elemento <context> for omitido, assim como na amostra <target> acima, os recursos JMS são pesquisados na instância local.

Procedimento 3.21. Antes de começar

1. Encerre o cliente e o servidor
2. 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.22. Altere seu provedor para o HornetQ

1. Transfira configurações

   A transferência das 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ões
     Esta 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ção
     Esta 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 Mensagem
     Esta configuração inclui os serviços de ponte implantados com o servidor do JBoss Messaging. Nenhum dos bridges é implantado por default, de forma que o nome do arquivo da implantação varia, dependendo de sua instalação.

2. 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: Seção 3.2.7.4, “Configuração de Mensagens com HornetQ”.

3. Migração de mensagens existentes

   Mova quaisquer mensagens do banco de dados do JBoss Messaging ao diário HornetQ usando a ponte JMS. As instruções para configuração do bridge JMS podem ser encontrados na: Seção 3.2.7.2, “Configuração do JMS Bridge para Migração de JMS Messages Existentes ao JBoss EAP 6”.

Procedimento 3.23. 

1. Inicie o JBoss EAP 6 com o clustering habilitado

   Para habilitar o clustering no JBoss EAP 5.x, você precisava iniciar suas instâncias do servidor usando o perfil all 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.

   1. Habilitação do cluster para servidores executando num managed domain

      Para habilitar o clustering para servidores iniciados usando o domain controller, atualize o seu domain.xml e determine um grupo de servidor para uso do seu perfil ha e grupo binding de soquete ha-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>
      

      Copy to Clipboard Toggle word wrap

   2. Habilitação do cluster para servidores autônomos

      Para habilitar o clustering para os servidores autônomos, inicie o servidor usando o arquivo de configuração apropriado conforme o seguinte: $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME

2. Especificação do endereço bind

   No JBoss EAP 5.x, você indicaria normalmente o endereço bind, usado para o clustering, usando o argumento da linha de comando -b conforme o seguinte: $ EAP_HOME/bin/run.sh -c all -b 192.168.0.2
   No JBoss EAP 6, os endereços bind são claramente definidos pelos socket bindings relevantes com os arquivos da configuração do JBoss EAP 6. Para os servidores iniciados usando o domain controller, os endereços bind são especificados com o arquivo domain/configuration/host.xml. Para os servidores autônomos, os endereços bind são especificados com o arquivo standalone-ha.xml:

   <interfaces>
     <interface name="management">
       <inet-address value="192.168.0.2"/>
         </interface>
         <interface name="public">
       <inet-address value="192.168.0.2"/>
     </interface>
   </interfaces>
   

   Copy to Clipboard Toggle word wrap

   <socket-binding-groups>
     <socket-binding-group name="ha-sockets" default-interface="public">
       <!-- ... -->
     </socket-binding-group>
   </socket-binding-groups>
   

   Copy to Clipboard Toggle word wrap

   A interface public é especificada na amostra acima como interface default para todos os sockets com o grupo socket binding ha-sockets.

3. Configure o jvmRoute para suportar o mod_jk e mod_proxy

   No JBoss EAP 5, o servidor da web jvmRoute foi configurado usando a propriedade no arquivo server.xml. No JBoss EAP 6, o atributo jvmRoute é configurado no subsistema da web do arquivo de combinação do servidor usando o atributo instance-id conforme o seguinte:

   <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false" instance-id="{JVM_ROUTE_SERVER}">
   
   

   Copy to Clipboard Toggle word wrap

   O {JVM_ROUTE_SERVER} acima deve ser substituído pela ID do servidor jvmRoute.
   O instance-id pode ser determinado usando o Management Console.

4. Especificação do endereço multicast e porta

   No JBoss EAP 5.x, você pode especificar o endereço multicast e a porta usada para a comunicação infra-cluster usando os argumentos da linha de comando -u e -m, respectivamente, como por exemplo: $ EAP_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>
   

   Copy to Clipboard Toggle word wrap

   <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>
   
   

   Copy to Clipboard Toggle word wrap

   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 o jboss.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}"/>
   
   

   Copy to Clipboard Toggle word wrap

   Você pode iniciar o seu servidor usando os argumentos da linha de comando: $ EAP_HOME/bin/domain.sh -Djboss.mcast.addr=228.11.11.11 -Djboss.mcast.port=45688

5. Uso da pilha de protocolo alternativo

   No JBoss EAP 5.x, você pode manipular a pilha de protocolo default para todos os serviços de clustering usando a propriedade de sistema jboss.default.jgroups.stack. $ EAP_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 o domain.xml ou standalone-ha.xml:

   <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
       <stack name="udp">
           <!-- ... -->
       </stack>
   </subsystem>
   

   Copy to Clipboard Toggle word wrap

6. Substituição da Replicação Buddy

   O JBoss EAP 5.x usou o JBoss Cache Buddy Replication para suprimir a replicação dos dados para todas as instâncias num cluster. É solicitado que você passe o argumento -Djboss.cluster.buddyRepl na linha de comando quando você inicia o servidor do JBoss.
   No JBoss EAP 6, a Replicação Buddy foi substituída pelo cache distribuído bastante superior do Infinispan ou modo DIST. A distribuição é um modo do clustering potente que permite o Infinispan a escalar de forma linear à medida que mais servidores são adicionados ao cluster. Segue abaixo uma amostra de como configurar o servidor para uso do modo de cache DIST.
   1. 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

      Copy to Clipboard Toggle word wrap
   2. 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
        

        Copy to Clipboard Toggle word wrap
      • Insira a seguinte linha de comando para o Windows:

        C:\>EAP_HOME\bin\jboss-cli.bat --connect
        

        Copy to Clipboard Toggle word wrap
      Você deve ver a seguinte resposta:

      Conectado ao controlador autônomo no localhost:9999

      Copy to Clipboard Toggle word wrap
   3. Imprima 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
      

      Copy to Clipboard Toggle word wrap
      Você deverá ver a seguinte resposta após cada comando:

      "outcome" => "success"
      

      Copy to Clipboard Toggle word wrap
      Esses comandos criam a seguinte configuração no subsistema infinispan do arquivo standalone-ha.xml:

      <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>
      
      

      Copy to Clipboard Toggle word wrap

      Refira-se ao capítulo 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 sobre este respeito.

Procedimento 3.24. Implantação do Serviço HA Singleton

1. Grave o aplicativo do serviço HA singleton.

   Segue abaixo uma amostra simples de um Serviço que está encapsulado com o decorador SingletonService a ser implantado como um serviço singleton.

   1. Crie um serviço singleton.

      A seguinte listagem é uma amostra do serviço singleton:

      package com.mycompany.hasingleton.service.ejb;
      
      import java.util.concurrent.atomic.AtomicBoolean;
      import java.util.logging.Logger;
      
      import org.jboss.as.server.ServerEnvironment;
      import org.jboss.msc.inject.Injector;
      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;
      import org.jboss.msc.value.InjectedValue;
      
      /**
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      public class EnvironmentService implements Service<String> {
          private static final Logger LOGGER = Logger.getLogger(EnvironmentService.class.getCanonicalName());
          public static final ServiceName SINGLETON_SERVICE_NAME = ServiceName.JBOSS.append("quickstart", "ha", "singleton");
          /**
           * A flag whether the service is started.
           */
          private final AtomicBoolean started = new AtomicBoolean(false);
      
          private String nodeName;
      
          private final InjectedValue<ServerEnvironment> env = new InjectedValue<ServerEnvironment>();
      
          public Injector<ServerEnvironment> getEnvInjector() {
              return this.env;
          }
      
          /**
           * @return the name of the server node
           */
          public String getValue() throws IllegalStateException, IllegalArgumentException {
              if (!started.get()) {
                  throw new IllegalStateException("The service '" + this.getClass().getName() + "' is not ready!");
              }
              return this.nodeName;
          }
      
          public void start(StartContext arg0) throws StartException {
              if (!started.compareAndSet(false, true)) {
                  throw new StartException("The service is still started!");
              }
              LOGGER.info("Start service '" + this.getClass().getName() + "'");
              this.nodeName = this.env.getValue().getNodeName();
          }
      
          public void stop(StopContext arg0) {
              if (!started.compareAndSet(true, false)) {
                  LOGGER.warning("The service '" + this.getClass().getName() + "' is not active!");
              } else {
                  LOGGER.info("Stop service '" + this.getClass().getName() + "'");
              }
          }
      }
      
      

      Copy to Clipboard Toggle word wrap

   2. Crie um singleton EJB para iniciar o serviço como um SingletonServiço na iniciação do servidor.

      A seguinte listagem é uma amostra de um singleton EJB que inicia um Singleton na iniciação do servidor:

      package com.mycompany.hasingleton.service.ejb;
      
      import java.util.Collection;
      import java.util.EnumSet;
      
      import javax.annotation.PostConstruct;
      import javax.annotation.PreDestroy;
      import javax.ejb.Singleton;
      import javax.ejb.Startup;
      
      import org.jboss.as.clustering.singleton.SingletonService;
      import org.jboss.as.server.CurrentServiceContainer;
      import org.jboss.as.server.ServerEnvironment;
      import org.jboss.as.server.ServerEnvironmentService;
      import org.jboss.msc.service.AbstractServiceListener;
      import org.jboss.msc.service.ServiceController;
      import org.jboss.msc.service.ServiceController.Transition;
      import org.jboss.msc.service.ServiceListener;
      import org.slf4j.Logger;
      import org.slf4j.LoggerFactory;
      
      
      /**
       * A Singleton EJB to create the SingletonService during startup.
       * 
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      @Singleton
      @Startup
      public class StartupSingleton {
        private static final Logger LOGGER = LoggerFactory.getLogger(StartupSingleton.class);
      
        /**
         * Create the Service and wait until it is started.<br/>
         * Will log a message if the service will not start in 10sec. 
         */
        @PostConstruct
        protected void startup() {
          LOGGER.info("StartupSingleton will be initialized!");
      
          EnvironmentService service = new EnvironmentService();
          SingletonService<String> singleton = new SingletonService<String>(service, EnvironmentService.SINGLETON_SERVICE_NAME);
          // if there is a node where the Singleton should deployed the election policy might set,
          // otherwise the JGroups coordinator will start it
          //singleton.setElectionPolicy(new PreferredSingletonElectionPolicy(new NamePreference("node2/cluster"), new SimpleSingletonElectionPolicy()));
          ServiceController<String> controller = singleton.build(CurrentServiceContainer.getServiceContainer())
              .addDependency(ServerEnvironmentService.SERVICE_NAME, ServerEnvironment.class, service.getEnvInjector())
              .install();
      
          controller.setMode(ServiceController.Mode.ACTIVE);
          try {
            wait(controller, EnumSet.of(ServiceController.State.DOWN, ServiceController.State.STARTING), ServiceController.State.UP);
            LOGGER.info("StartupSingleton has started the Service");
          } catch (IllegalStateException e) {
            LOGGER.warn("Singleton Service {} not started, are you sure to start in a cluster (HA) environment?",EnvironmentService.SINGLETON_SERVICE_NAME);
          }
        }
      
        /**
         * Remove the service during undeploy or shutdown
         */
        @PreDestroy
        protected void destroy() {
          LOGGER.info("StartupSingleton will be removed!");
          ServiceController<?> controller = CurrentServiceContainer.getServiceContainer().getRequiredService(EnvironmentService.SINGLETON_SERVICE_NAME);
          controller.setMode(ServiceController.Mode.REMOVE);
          try {
            wait(controller, EnumSet.of(ServiceController.State.UP, ServiceController.State.STOPPING, ServiceController.State.DOWN), ServiceController.State.REMOVED);
          } catch (IllegalStateException e) {
            LOGGER.warn("Singleton Service {} has not be stopped correctly!",EnvironmentService.SINGLETON_SERVICE_NAME);
          }
        }
      
        private static <T> void wait(ServiceController<T> controller, Collection<ServiceController.State> expectedStates, ServiceController.State targetState) {
          if (controller.getState() != targetState) {
            ServiceListener<T> listener = new NotifyingServiceListener<T>();
            controller.addListener(listener);
            try {
              synchronized (controller) {
                int maxRetry = 2;
                while (expectedStates.contains(controller.getState()) && maxRetry > 0) {
                  LOGGER.info("Service controller state is {}, waiting for transition to {}", new Object[] {controller.getState(), targetState});
                  controller.wait(5000);
                  maxRetry--;
                }
              }
            } catch (InterruptedException e) {
              LOGGER.warn("Wait on startup is interrupted!");
              Thread.currentThread().interrupt();
            }
            controller.removeListener(listener);
            ServiceController.State state = controller.getState();
            LOGGER.info("Service controller state is now {}",state);
            if (state != targetState) {
              throw new IllegalStateException(String.format("Failed to wait for state to transition to %s.  Current state is %s", targetState, state), controller.getStartException());
            }
          }
        }
      
        private static class NotifyingServiceListener<T> extends AbstractServiceListener<T> {
          @Override
          public void transition(ServiceController<? extends T> controller, Transition transition) {
            synchronized (controller) {
              controller.notify();
            }
          }
        }
      }
      
      

      Copy to Clipboard Toggle word wrap

   3. Crie um Bean de Sessão Stateless para acesso ao serviço a partir de um cliente.

      Segue abaixo uma amostra de um bean de sessão stateless que acessa o serviço de um cliente:

      package com.mycompany.hasingleton.service.ejb;
      
      import javax.ejb.Stateless;
      
      import org.jboss.as.server.CurrentServiceContainer;
      import org.jboss.msc.service.ServiceController;
      import org.slf4j.Logger;
      import org.slf4j.LoggerFactory;
      
      /**
       * A simple SLSB to access the internal SingletonService.
       * 
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      @Stateless
      public class ServiceAccessBean implements ServiceAccess {
          private static final Logger LOGGER = LoggerFactory.getLogger(ServiceAccessBean.class);
      
          public String getNodeNameOfService() {
              LOGGER.info("getNodeNameOfService() is called()");
              ServiceController<?> service = CurrentServiceContainer.getServiceContainer().getService(
                      EnvironmentService.SINGLETON_SERVICE_NAME);
              LOGGER.debug("SERVICE {}", service);
              if (service != null) {
                  return (String) service.getValue();
              } else {
                  throw new IllegalStateException("Service '" + EnvironmentService.SINGLETON_SERVICE_NAME + "' not found!");
              }
          }
      }
      
      

      Copy to Clipboard Toggle word wrap

   4. Crie uma interface de lógica comercial para o SingletonService.

      A seguinte amostra é uma interface lógica comercial para o SingletonService:

      package com.mycompany.hasingleton.service.ejb;
      
      import javax.ejb.Remote;
      
      /**
       * Business interface to access the SingletonService via this EJB
       * 
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      @Remote
      public interface ServiceAccess {
          public abstract String getNodeNameOfService();
      } 
      
      
      

      Copy to Clipboard Toggle word wrap

2. Inicie cada instância do JBoss EAP 6 com o clustering habilitado.

   O método de habilitação com cluster depende se os servidores forem autônomos ou executando num managed domain.

   1. Habilite o clustering para servidores executando num managed domain.

      Você pode habilitar o clustering usando o Management CLI ou você pode editar manualmente o arquivo de configuração.

      • Habilite o clustering usando o Management CLI.

        1. Inicie o seu domain controller.

        2. Abra a janela de comando para o seu sistema operacional.

        3. Conecte ao Management CLI passando o endereço IP do domain controller ou nome DNS.

           Nesta amostra, assuma que o endereço IP do domain controller é 192.168.0.14.
           • Insira a seguinte linha de comando para o Linux:

             $ EAP_HOME/bin/jboss-cli.sh --connect --controller=192.168.0.14
             

             Copy to Clipboard Toggle word wrap
           • Insira a seguinte linha de comando para o Windows:

             C:\>EAP_HOME\bin\jboss-cli.bat --connect --controller=192.168.0.14
             

             Copy to Clipboard Toggle word wrap
           Você deverá observar a seguinte resposta:

           Conectado ao domain controller no 192.168.0.14

           Copy to Clipboard Toggle word wrap

        4. Adicione o grupo de servidor main-server.

           [domain@192.168.0.14:9999 /] /server-group=main-server-group:add(profile="ha",socket-binding-group="ha-sockets") 
           {
               "outcome" => "success",
               "result" => undefined,
               "server-groups" => undefined
           }
           

           Copy to Clipboard Toggle word wrap

        5. Crie um servidor nomeado server-one e adicione-o ao grupo do servidor main-server.

           [domain@192.168.0.14:9999 /]  /host=station14Host2/server-config=server-one:add(group=main-server-group,auto-start=false)
           {
               "outcome" => "success",
               "result" => undefined
           }
           

           Copy to Clipboard Toggle word wrap

        6. Configure o JVM para o grupo do servidor main-server.

           [domain@192.168.0.14:9999 /] /server-group=main-server-group/jvm=default:add(heap-size=64m,max-heap-size=512m)
           {
               "outcome" => "success",
               "result" => undefined,
               "server-groups" => undefined
           }
           

           Copy to Clipboard Toggle word wrap

        7. Crie um servidor nomeado server-two, coloque-o num grupo de servidor separado e configure a porta de deslocamento para 100.

           [domain@192.168.0.14:9999 /]  /host=station14Host2/server-config=server-two:add(group=distinct2,socket-binding-port-offset=100)
           {
               "outcome" => "success",
               "result" => undefined
           }
           

           Copy to Clipboard Toggle word wrap

      • Habilite o clustering editando manualmente os arquivos de configuração do servidor.

        1. Interrompa o servidor do JBoss EAP 6.

           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.

        2. Abra o arquivo de configuração domain.xml para edição

           Determine um grupo de servidor para uso do seu perfil ha e grupo socket binding ha-sockets conforme abaixo:

           <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-groups>
           
           

           Copy to Clipboard Toggle word wrap

        3. Abra o arquivo de configuração host.xml para edição

           Modifique o arquivo conforme o seguinte:

           <servers>
             <server name="server-one" group="main-server-group" auto-start="false"/>
             <server name="server-two" group="distinct2">
               <socket-bindings port-offset="100"/>
             </server>
           <servers>
           
           

           Copy to Clipboard Toggle word wrap

        4. Inicie o servidor.

           • Digite EAP_HOME/bin/domain.sh para o Linux
           • Digite EAP_HOME\bin\domain.bat para o Microsoft Windows

   2. Habilitação do cluster para servidores autônomos

      Para habilitar o cluster para servidores autônomos, inicie o servidor usando o nome do nó e o arquivo da configuração standalone-ha.xml conforme abaixo:
      • Digite EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME para o Linux
      • Digite EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME para o Microsoft Windows

   Nota

   Configure o arquivo standalone-ha.xml para cada instância do servidor efetuar o bind numa interface separada, com o objetivo de evitar conflitos quando executando múltiplos servidores numa máquina. Alternativamente, você pode iniciar as instâncias do servidor subsequentes com uma porta de deslocamento usando o argumento conforme a seguinte linha de comando: -Djboss.socket.binding.port-offset=100.

3. Implantação do aplicativo aos servidores

   Caso você use o Maven para implantar seu aplicativo, use o seguinte comando Maven para implantar o servidor executando nas portas default:
   mvn clean install jboss-as:deploy
   Para implantar os servidores adicionais, passe o nome do servidor e o número da porta com a linha de comando:
   mvn clean package jboss-as:deploy -Ddeploy.hostname=localhost -Ddeploy.port=10099

Procedimento 3.25. Adição da Configuração do Projeto Maven para a Invocação Remota dos Beans de Sessão

1. Adicione as dependências do projeto solicitadas

   O pom.xml para o projeto deve ser atualizado para incluir as dependências necessárias.

2. Adicione o arquivo jboss-ejb-client.properties

   O API do cliente JBoss EJB espera encontrar um arquivo na raiz do projeto nomeado jboss-ejb-client.properties que contém a informação da conexão para o serviço JNDI. Adicione este arquivo ao diretório src/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
   
   

   Copy to Clipboard Toggle word wrap
   Altere o portal e o nome do host para coincidir com o seu servidor. O 4447 é o número de porta default. Configure a linha SSL_ENABLED para true e descomente a linha SSL_STARTTLS. A interface remota no contêiner suporta as conexões com e sem segurança usando a mesma porta.

3. Adicione dependências para as interfaces comerciais

   Adicione as dependências Maven ao pom.xml para interfaces comerciais remotas dos beans de sessão.

   <dependency>
      <groupId>org.jboss.as.quickstarts</groupId>
      <artifactId>jboss-as-ejb-remote-server-side</artifactId>
      <type>ejb-client</type>
      <version>${project.version}</version>
   </dependency>
   

   Copy to Clipboard Toggle word wrap

Procedimento 3.26. Obtenção de um Proxy Bean usando o JNDI e Métodos de Invocação do Bean

1. Manuseio das exceções checadas

   Os métodos usados no seguinte código (InitialContext() e lookup()) possuem uma exceção de checagem do tipo javax.naming.NamingException. Essas chamadas de método devem tanto ser inseridas num bloco de tentativa/captura que captura o NamingException ou num método que é declarado ao lançar o NamingException. O ejb-remote quickstart usa a segunda técnica.

2. 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);
   

   Copy to Clipboard Toggle word wrap
   As propriedades de conexão para o serviço JNDI são lidas a partir do arquivo jboss-ejb-client.properties.

3. Uso do método lookup() do Contextp JNDI para obter um proxy de bean

   Invoque o método lookup() 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-as-ejb-remote-server-side/CalculatorBean!" + 
       RemoteCalculator.class.getName());
   
   

   Copy to Clipboard Toggle word wrap
   Os nomes do JNDI do bean de sessão são definidos usando a síntese especial.

4. Métodos de Invocação

   Agora que você possui um objeto de bean de proxy você pode 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);
   

   Copy to Clipboard Toggle word wrap
   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.

Procedimento 3.27. Execute o EJB 2.x no JBoss EAP 6

1. Modifique o Código em uso para as Novas Regras do JNDI Namespace

   A partir do EJB 3.0, você deverá usar o prefixo completo do JNDI com o EJB 2.x. Consulte a Seção 3.1.8.1, “Atualização dos Nomes JNDI Namespace do Aplicativo” para maiores informações sobre as amostras de regras e códigos do JNDI.
   As amostras que apresentam como atualizar os JNDI namespaces a partir das liberações antigas 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”.

2. 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.

3. Substitua o arquivo do descritor da implantação jboss.xml

   O descritor da implantação jboss-ejb3.xml substitui o descritor da implantação jboss.xml para substituição e adição à recursos fornecidos pelo Java Enterprise Edition (EE - Edição do Java Enterprise) definidos no descritor da implantação ejb-jar.xml. O novo arquivo é incompatível com o jboss.xml e o jboss.xml é agora ignorado nas implantações.

4. Inicie o Servidor com os Perfis Completos

   O EJB 2.x requer o Perfil Completo da Edição do Java Enterprise 6. Passe o argumento -c standalone-full.xml à linha de comando quando iniciando o servidor, com o objetivo de iniciar o JBoss EAP 6 com o perfil completo.

5. O clustering não é mais suportado

   O clustering dos beans de entidade EJB 2.x não é mais suportado no JBoss EAP 6.

Procedimento 3.28. Migração dos Arquivos Seam 2.2

1. Atualização da configuração da fonte de dados

   Algumas das amostras Seam 2.2 usam a fonte de dados JDBC default nomeada java:/ExampleDS. A fonte de dados default foi alterada no JBoss EAP 6 para java:jboss/datasources/ExampleDS. Caso seu aplicativo usar a fonte de dados da amostra, você pode realizar o seguinte:

   • 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 elemento jta-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>
     

     Copy to Clipboard Toggle word wrap
   • 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 persistida na iniciação 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>
     

     Copy to Clipboard Toggle word wrap
   • 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.1. 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
     

     Copy to Clipboard Toggle word wrap

   Para maiores informações de como configurar a fonte de dados, consulte a Seção 3.1.6.2, “Atualização da Configuração da Fonte de Dados”.

2. 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 arquivo jboss-deployment-structure.xml no diretório META-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>
   

   Copy to Clipboard Toggle word wrap

   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”.

3. 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 o ClassNotFoundExceptions ou ClassCastExceptions 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
   

   Copy to Clipboard Toggle word wrap

4. 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 do META-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>
   

   Copy to Clipboard Toggle word wrap
   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.

5. Depuração e resolução dos erros Seam 2.2 JNDI

   Quando você migrar o aplicativo Seam 2.2, você poderá ver erros javax.naming.NameNotFoundException no log conforme o seguinte:

   javax.naming.NameNotFoundException: Name 'jboss-seam-booking' not found in context ''

   Copy to Clipboard Toggle word wrap

   Caso você não deseje modificar as pesquisas JNDI através do código, você pode modificar o arquivo components.xml do aplicativo, conforme abaixo:

   1. 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"/>
      
      

      Copy to Clipboard Toggle word wrap

   2. 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
      

      Copy to Clipboard Toggle word wrap

   3. Adição dos elementos do componente

      Para cada mensagem INFO binding JNIDI, adicione um elemento component correspondente ao arquivo components.xml:

      <component class="org.jboss.seam.example.booking.AuthenticatorAction" jndi-name="java:app/jboss-seam-booking.jar/AuthenticatorAction" />
      

      Copy to Clipboard Toggle word wrap
   Para maiores informações sobre 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”.