1. Primeiro, veja o empacotamento do seu aplicativo e as suas dependências. Para mais informações, consulte: Seção 3.1.2.3, “Atualização das Dependências do Aplicativo Devido às Alterações de Carregamento de Classe”
2. Caso o seu aplicativo realize o registro em log, será necessário especificar corretamente as dependências do módulo. Para mais informações, consulte: Seção 3.1.4.1, “Modificação das Dependências de Registro em Log”
3. Devido às alterações do carregamento de classe modular, pode ser que seja necessário alterar a estrutura do empacotamento do seu EAR ou WAR. Para mais informações, consulte: Seção 3.1.5.1, “Modificação do Empacotamento de EARS e WARs”

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

1. Compreendendo as dependências implícitas

   Os implantadores dentro do servidor adicionam automaticamente e de forma implícita algumas dependências de módulo comumente usadas, como javax.api e sun.jdk. Isto permite que as classes sejam visíveis à implantação durante o tempo de execução e reduz a tarefa do desenvolvedor de adicionar explicitamente as dependências. Para obter mais detalhes sobre como e quando essas dependências implícitas são adicionadas, consulte Implicit Module Dependencies no capítulo entitulado Class Loading and Modules no guia Development Guide para o JBoss EAP 6 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, caso contrário as dependências ausentes resultarão em erros de implantação ou de tempo de execução. Caso esteja faltando uma dependência, você encontrará rastreios como ClassNotFoundExceptions ou NoClassDefFoundErrors no log do servidor. Caso mais de um módulo carregue o mesmo JAR ou um módulo carregue uma classe que estenda uma classe carregada por um módulo diferente, você encontrará rastreios como ClassCastExceptions no servidor do log. Para especificar as dependências explicitamente, modifique o MANIFEST.MF ou crie um arquivo de descritor de implantação específico do JBoss jboss-deployment-structure.xml. Para mais informações sobre as dependências de módulos, consulte Overview of Class Loading and Modules no capítulo entitulado Class Loading and Module no guia Development Guide para o JBoss EAP 6 em https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

Procedimento 3.2. Alteração da Localização das Propriedades ResourceBundle

1. Caso esteja implantando um arquivo WAR, essas propriedades devem ser empacotadas na pasta WEB-INF/classes/ do WAR.
2. Caso queira que essas propriedades fiquem acessíveis a todos os componentes em um EAR, elas devem ser empacotadas na raiz de um JAR e, então, o JAR deve ser colocado 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

   2. Mova os arquivos de propriedades para o 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>

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 Gerenciamento CLI.
        • Para o Linux, insira o seguinte na linha de comando:

           EAP_HOME/bin/jboss-cli.sh --connect

        • Para o Windows, insira o seguinte na linha de comando:

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

        Você deverá ver a seguinte resposta:

        Conectado ao controlador autônomo em localhost:9999

     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"}])

        Você deverá ver o seguinte resultado:

        {"outcome" => "success"}

   • Siga essas etapas caso prefira editar manualmente o arquivo de configuração do servidor.
     1. Interrompa o servidor e abra o arquivo de configuração do servidor em um editor de texto. Caso esteja executando um servidor autônomo, o arquivo será EAP_HOME/standalone/configuration/standalone.xml ou, caso esteja executando um domínio gerenciado, o arquivo será EAP_HOME/domain/configuration/domain.xml.
     2. Encontre o subsistema ee e adicione o módulo global para myorg-conf. Segue um exemplo do elemento do subsistema ee modificado para a inclusão do elemento myorg-conf:

        Exemplo 3.1. elemento myorg-conf

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

3. Presumindo que você copiou um arquivo nomeado my.properties à localização de módulo correta, você poderá agora carregar os arquivos de propriedades usando um código semelhante ao seguinte:

   Exemplo 3.2. Carregue o arquivo de propriedades

   Thread.currentThread().getContextClassLoader().getResource("my.properties");

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

1. Seção 3.1.4.2, “Atualização do Código de Aplicativo para Estruturas de Registro em Log de Terceiros”
2. Seção 3.1.4.3, “Modificação do Código para Uso da Nova Estrutura de Registro do JBoss”

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

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

2. Posicione o arquivo jboss-deployment-structure.xml no diretório META-INF/ ou no diretório WEB-INF/, caso esteja implantando um WAR. Do contrário, posicione-o no diretório META-INF/ caso esteja implantando um EAR. Se a sua implantação incluir componentes dependentes, o módulo também deve ser removido para cada subimplantação.
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. Caso prefira posicionar o arquivo no diretório lib/ de seu WAR, você deve especificar o caminho <resource-root> no arquivo jboss-deployment-structure.xml.

   <jboss-deployment-structure>
       <deployment>
           <!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
           <exclusions>
               <module name="org.apache.log4j" />
           </exclusions>
           <resources>
               <resource-root path="lib" />
           </resources>
       </deployment>
   </jboss-deployment-structure>
   

4. Inicie o servidor do JBoss EAP 6 com o seguinte argumento de tempo de execução para evitar que um ClassCastException apareça no console no momento de implantação do aplicativo:

   -Dorg.jboss.as.logging.per-deployment=false

5. Implante seu aplicativo.

Procedimento 3.6. Configuração das Dependências de Registro para o JBoss EAP 6.3 ou versões posteriores

1. Inicie o servidor do JBoss EAP 6 com o seguinte argumento de tempo de execução para evitar que um ClassCastException apareça no console no momento de implantação do aplicativo:

   -Dorg.jboss.as.logging.per-deployment=false

2. Abra um terminal e conecte-se ao Gerenciamento CLI.
   • Para o Linux, insira a seguinte linha de comando:

     $ EAP_HOME/bin/jboss-cli.sh --connect
     

   • Para o Windows, insira a seguinte linha de comando:

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

3. Modifique o atributo add-logging-api-dependencies no subsistema de registro.
   Este atributo controla se o contêiner deve adicionar ou não as dependências API implícitas de registro às suas implantações.

   • Se definido como true, que é o padrão, todas as dependências API implícitas de registro serão adicionadas.
   • Se definido como false, as dependências não serão adicionadas às suas implantações.
   Para remover as dependências de estrutura de registro em log de terceiros, você deve definir este atributo como false usando o seguinte comando:

   /subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)

   Este comando adiciona o elemento <add-logging-api-dependencies> ao subsistema logging do arquivo de configuração standalone.xml.

   <subsystem xmlns="urn:jboss:domain:logging:1.4">
       <add-logging-api-dependencies value="false"/>
       ....
   </subsystem>
   

4. Implante seu aplicativo.

Procedimento 3.7. Modificação do Código e das Dependências para Uso da Estrutura de Registro do JBoss

1. Alteração de suas importações e código de registro

   Segue abaixo um exemplo do código que usa a nova estrutura de registro do JBoss:

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

2. Adição da dependência de registro

   O JAR contendo as classes de registro do JBoss 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
   

   Por favor consulte Seção 3.1.2.3, “Atualização das Dependências do Aplicativo Devido às Alterações de Carregamento de Classe” e Seção 4.2.1, “Depuração e Solução de Problemas de Migração” para mais informações sobre como encontrar a dependência do módulo.

Procedimento 3.8. Modificação do empacotamento de arquivos

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 subimplantação EJB jar dentro do EAR é um módulo separado. As classes não possuem acesso às classes em outros módulos dentro do EAR, a não ser que as dependências explícitas tenham sido definidas. As subimplantações sempre possuem uma dependência automática no módulo pai que fornece-as acesso às classes no diretório EAR/lib/. No entanto, as subimplantações nem sempre possuem uma dependência automática para permití-las acessar umas às outras. 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>

   Por padrão, isto é configurado como falso, permitindo que as subimplantações vejam as classes pertencentes às outras subimplantações dentro do EAR.
   Para mais informações sobre o carregamento de classe, consulte o capítulo entitulado Class Loading and Modules no guia Development Guide para o JBoss EAP 6 em https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

1. Se seu aplicativo usa uma fonte de dados, consulte : Seção 3.1.6.2, “Atualização da Configuração da DataSource”.
2. Se o seu aplicativo usa JPA e atualmente agrupa JARs Hibernate, consulte: Seção 3.1.6.4, “Configuração da Fonte de Dados para o Hibernate ou JPA” para opções de migração.
3. Se o seu aplicativo usa um adaptador de recursos, consulte: Seção 3.1.6.5, “Atualização da Configuração do Adaptador de Recurso”.
4. Revise as informações a seguir sobre como configurar as alterações para segurança básica: Seção 3.1.7.1, “Configuração das Alterações de Segurança do Aplicativo”.

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

1. Instalação do Driver JDBC.

   1. Instalação do Driver JDBC como uma implantação.

      Esta é a maneira recomendada de instalar o driver. Quando o driver JDBC é instalado como uma implantação, ele é implantado como um JAR regular. Caso a instância do JBoss EAP 6 esteja sendo executada como um servidor autônomo, copie o JAR compatível com o JDBC 4.0 no diretório EAP_HOME/standalone/deployments/. Para um domínio gerenciado, você deve usar o Console de Gerenciamento ou Gerenciamento CLI para implantar o JAR nos grupos do servidor.
      Segue um exemplo de um driver MySQL JDBC instalado como uma implantação no servidor autônomo:

      $cp mysql-connector-java-5.1.15.jar EAP_HOME/standalone/deployments/

      Qualquer driver compatível com o JDBC 4.0 é automaticamente reconhecido e instalado no sistema por nome e versão. Um JAR compatível com o JDBC 4.0 contém um arquivo de texto nomeado META-INF/services/java.sql.Driver que especifica o(s) nome(s) da classe do driver. Caso o driver não seja 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

      • Crie um arquivo java.sql.Driver no diretório de implantação. Para uma instância do JBoss EAP 6 executando como um servidor autônomo, o arquivo deve ser posicionado aqui: EAP_HOME/standalone/deployments/META-INF/services/java.sql.Driver. Caso o servidor esteja em um domínio gerenciado, você deve usar o Console de Gerenciamento ou o Gerenciamento CLI para implantar o arquivo.
      Os aspectos positivos desta abordagem são:

      • Este é o método mais simples já que não há necessidade de definir um módulo.
      • Quando o servidor executa em um domínio gerenciado, as implantações que usam esta abordagem são propagadas automaticamente a todos os servidores no domínio. Isto significa que o administrador não precisa distribuir o driver JAR manualmente.

      Os aspectos negativos desta abordagem são:

      • Se o driver JDBC consiste em mais de um JAR, por exemplo o driver JAR mais um JAR de licença dependente ou um JAR de localização, você não pode instalar o driver como uma implantação. O JDBC deve ser instalado como um módulo principal.
      • Caso o driver não seja 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 para um JAR ou sobreposto no diretório deployments/.

   2. Instalação do Driver JDBC como um módulo principal.

      Para instalar um driver JDBC como um módulo principal, uma estrutura do caminho do arquivo sob o diretório EAP_HOME/modules/ deve ser criada. Esta estrutura contém o JAR do driver JDBC, JARs de localização ou licenças adicionais do fornecedor e um arquivo module.xml para a definição do módulo.

      • Instalação do Driver MySQL JDBC como um módulo principal

        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 driver MySQL JDBC:

           <?xml version="1.0" encoding="UTF-8"?>
           <module xmlns="urn:jboss:module:1.0" name="com.mysql">
           <resources>
               <resource-root path="mysql-connector-java-5.1.15.jar"/>
           </resources>
           <dependencies>
               <module name="javax.api"/>
           </dependencies>
           </module>
           
           

           O nome do módulo, "com.mysql", coincide com a estrutura do diretório para esse módulo. O elemento <dependencies> é usado para especificar as dependências do módulo em outros módulos. Neste caso, como no caso de todas as fonte de dados JDBC, ele é 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 possua espaço no início do arquivo module.xml ou obterá um erro "Novas dependências ausentes/não satisfatórias" para este driver.
        3. Copie MySQL JDBC driver JAR no diretório EAP_HOME/modules/com/mysql/main/:

           $ cp mysql-connector-java-5.1.15.jar EAP_HOME/modules/com/mysql/main/

      • Instalação do driver IBM DB2 JDBC e do JAR de licença como um módulo principal.

        Este exemplo é fornecido apenas para demonstrar a implantação de drivers que requerem JARs além do JAR do Driver JDBC.
        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 a licença e o driver IBM DB2 JDBC:

           <?xml version="1.0" encoding="UTF-8"?>
           <module xmlns="urn:jboss:module:1.1" name="com.ibm.db2">
             <resources>
               <resource-root path="db2jcc.jar"/>
               <resource-root path="db2jcc_license_cisuz.jar"/>
             </resources>
             <dependencies>
               <module name="javax.api"/>
               <module name="javax.transaction.api"/>
             </dependencies>
           </module>
           

           Nota

           Certifique-se de que você NÃO possua espaço no início do arquivo module.xml ou obterá um erro "Novas dependências ausentes/não satisfatórias" para este driver.
        3. Copie o driver JDBC e o JAR de licença no 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/

      Os aspectos positivos desta abordagem são:

      • Esta é a única abordagem que funciona quando o driver JDBC consiste em 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 criar 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 em execução em um domínio gerenciado.

2. Configuração da fonte de dados.

   1. Adição do driver do banco de dados.

      Adicione o elemento <driver> ao elemento <drivers> do mesmo arquivo. Mais uma vez, isto contém algumas das mesmas informações sobre a fonte de dados 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) do driver no JAR. Um driver que é compatível com o JDBC 4.0 não requer um elemento <driver-class>, desde que ele já esteja especificado no JAR. Segue um exemplo do elemento do driver para um driver MySQL compatível com o JDBC 4.0:

      <driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"/>
      

      Um driver que não seja compatível com o JDBC 4.0 requer um atributo <driver-class> para identificar a classe do driver já que não há um arquivo META-INF/services/java.sql.Driver que especifique o nome da classe do driver. Segue um exemplo do elemento do driver para um 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>
      

   2. Criação da fonte de dados.

      Crie um elemento <datasource> na seção <datasources> do arquivo standalone.xml. Este arquivo contém muitas das mesmas informações sobre a 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 a sua alteração seja efetivada ao reiniciar o servidor.
      Segue um exemplo de um elemento da 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>
      

3. Atualização das referências JNDI no código do aplicativo.

   Você deve substituir os antigos nomes de pesquisa JNDI no código fonte do aplicativo para usar os novos nomes padronizados da fonte de dados JNDI que você definiu anteriormente. Consulte Seção 3.1.8.4, “Modificação do Aplicativo para Seguir as Novas Regras do Namespace JNDI” para mais informações.
   Você deve substituir também quaisquer anotações @Resource existentes que acessam a fonte de dados para utilizar o novo nome JNDI. Por exemplo:

   @Resource(name = "java:/YourDatasourceName").
   

Procedimento 3.10. Remoção do pacote Hibernate

1. Remova os JARs Hibernate das pastas da biblioteca do seu aplicativo.
2. Remova ou converta em comentário o elemento <hibernate.transaction.manager_lookup_class> no seu arquivo persistence.xml, já que este elemento não é necessário.

Procedimento 3.11. Desabilitação das Verificações de Autorização Adicionais

• Você pode desabilitar as verificações de autorização adicionais e continuar usando as implantações PicktLink existentes usando um dos seguintes métodos.

  • Definição de uma Propriedade em Todo o Sistema

    As verificações de autorização adicionais podem ser desabilitadas ao nível do servidor definindo o valor da propriedade do sistema org.jboss.ws.cxf.disableHandlerAuthChecks para true. Este método afeta qualquer implantação realizada ao servidor do aplicativo.
    Consulte o tópico entitulado Configure System Properties Using the Management CLI no guia Administration and Configuration Guide do JBoss EAP para mais informações sobre como definir uma propriedade de sistema.

  • Criação de uma Propriedade no Arquivo de Descritor de Serviços Web da Implantação

    As verificações de autorização adicionais podem ser desabilitadas ao nível da implantação definindo o valor da propriedade org.jboss.ws.cxf.disableHandlerAuthChecks para true no arquivo jboss-webservices.xml. Este método impacta somente a implantação específica.
    1. Crie um arquivo jboss-webservices.xml no diretório META-INF/ da implantação que deseja desabilitar as verificações da autorização adicionais.
    2. Adicione o seguinte conteúdo:

       <?xml version="1.1" encoding="UTF-8"?>
       <webservices xmlns="http://www.jboss.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         version="1.2" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee">
         <property>
           <name>org.jboss.ws.cxf.disableHandlerAuthChecks</name>
           <value>true</value>
         </property>
       </webservices>

Procedimento 3.12. Modificação das pesquisas JNDI

1. Saiba mais Seção 3.1.8.2, “Nomes JNDI EJB Portáteis ”
2. Seção 3.1.8.3, “Revisão das Regras do Namespace JNDI”
3. Seção 3.1.8.4, “Modificação do Aplicativo para Seguir as Novas Regras do Namespace JNDI”

Procedimento 3.13. Configuração do Aplicativo

1. Copie os JARs necessários do Hibernate 3 para a biblioteca do seu aplicativo.

   Você pode conseguir resolver o problema copiando os JARs específicos do Hibernate 3 que contêm as classes faltantes no diretório lib/ do aplicativo ou adicionando-os ao caminho de classe usando algum outro método. Em alguns casos, isto pode resultar em ClassCastExceptions ou em outros problemas de carregamento de classe devido ao uso misto das versões Hibernate. Caso isto aconteça, você precisará usar a próxima abordagem.

2. Instrua o servidor para usar apenas as bibliotecas do Hibernate 3.

   O JBoss EAP 6 permite que você empacote os jars do provedor de persistência Hibernate 3.5 (ou posterior) com o aplicativo. Para direcionar o servidor para o uso apenas das bibliotecas do Hibernate 3 e excluir as bibliotecas do Hibernate 4, você precisa determinar jboss.as.jpa.providerModule como hibernate3-bundled no persistence.xml, conforme a seguir:

   <?xml version="1.0" encoding="UTF-8"?>
   <persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
       <persistence-unit name="plannerdatasource_pu">
           <description>Hibernate 3 Persistence Unit.</description>
           <jta-data-source>java:jboss/datasources/PlannerDS</jta-data-source>
           <properties>
               <property name="hibernate.show_sql" value="false" />
               <property name="jboss.as.jpa.providerModule" value="hibernate3-bundled" />
           </properties>
       </persistence-unit>
   </persistence>
   

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

3. Desabilite o cache de segundo nível do Hibernate

   O cache de segundo nível para o Hibernate 3 não exibe o mesmo comportamento com o JBoss EAP 6, como fazia nas versões anteriores. Caso você esteja usando o cache de segundo nível do Hibernate com o seu aplicativo, você deve desativá-lo até que ele seja atualizado para o Hibernate 4. Para desativar o cache de segundo nível, configure o <hibernate.cache.use_second_level_cache> como false no arquivo persistence.xml.

Procedimento 3.14. Atualização do aplicativo para a utilização do Hibernate 4

1. O comportamento padrão do gerador de sequência de incremento automático foi alterado no JBoss EAP 6. Consulte Seção 3.2.2.5, “Preservação do Comportamento Existente do Valor de Identidade do Hibernate Gerado Automaticamente ” para mais informações.
2. Estabeleça a versão do Hibernate sendo utilizada pelo aplicativo e escolha o procedimento de atualização correto.
   • Seção 3.2.2.6, “Migração de seu Aplicativo Hibernate 3.3.x para Hibernate 4.x ”
   • Seção 3.2.2.7, “Migração de seu Aplicativo Hibernate 3.5.x para Hibernate 4.x”
3. Consulte Seção 3.2.2.8, “Modificação das Propriedades de Persistência para os Aplicativos Hibernate e Seam Migrados que Executam em um Ambiente Clusterizado” caso planeja executar o seu aplicativo em um ambiente com cluster.

1. Mapeie os tipos de Hibernate text para JDBC LONGVARCHAR

   Nas versões anteriores ao Hibernate 3.5, o tipo 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 possua propriedades configuradas como type="text" que devem ser mapeadas para JDBC CLOB, você precisa seguir uma das opções abaixo:
   1. Se o seu aplicativo utiliza arquivos de mapeamento hbm, altere a propriedade para type="materialized_clob".
   2. Se o seu aplicativo utiliza anotações, você deve substituir @Type(type = "text") por @Lob.

2. Revise o código para encontrar alterações nos tipos de valores retornados

   As projeções de critérios de agregação numérica agoram retornam o mesmo tipo de valor que seus equivalentes HQL. Como consequência, os tipos retornados das seguintes projeções em org.hibernate.criterion foram alterados.
   1. Devido às alterações em CountProjection, Projections.rowCount(), Projections.count(propertyName) e Projections.countDistinct(propertyName), as projeções count e count distinct agora retornam um valor Long.
   2. Devido às alterações em Projections.sum(propertyName), as projeções sum retornam agora um tipo de valor que depende do tipo de propriedade.

      Nota

      Falha em modificar o código do seu aplicativo pode resultar em java.lang.ClassCastException.
      1. Para as propriedades mapeadas como Long, Short, Integer ou tipos integer primitivos, o valor Long é retornado;
      2. Para as propriedades mapeadas como Float, Double ou tipos de ponto flutuante primitivo, o valor Double é retornado.

1. Mescle AnnotationConfiguration na Configuração.
   Embora AnnotationConfiguration tenha sido preterido, ele não deve afetar a sua migração.
   Caso você ainda 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. Se você se basear na estratégia de nomeação para usar como padrão o nome de uma tabela de associação (muitos-para-muitos e coleções de elementos), você pode encontrar esse problema. Para resolver isto, você pode solicitar ao Hibernate que utilize org.hibernate.cfg.DefaultNamingStrategy de legacia chamando Configuration#setNamingStrategy e passando-o org.hibernate.cfg.DefaultNamingStrategy#INSTANCE.
2. Modifique os namespaces para estarem de acordo com os novos nomes dos arquivos Hibernate DTD, conforme descrito na tabela abaixo.

   Tabela 3.6. Tabela de Mapeamento de Namespace DTD

   Namespace DTD Anterior	Namespace DTD Novo
   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

3. Modifique as variáveis do ambiente.
   1. Caso você esteja usando Oracle e as propriedades materialized_clob ou materialized_blob, a variável de ambiente global hibernate.jdbc.use_streams_for_binary deve ser configurada como verdadeira.
   2. Caso você esteja usando PostgreSQL e as propriedades CLOB ou BLOB, a variável de ambiente global hibernate.jdbc.use_streams_for_binary deve ser configurada como falsa.

Procedimento 3.15. Configuração das propriedades de persistência para executar em um ambiente clusterizado

1. Configure o valor hibernate.session_factory_name como um nome único. Este nome deve ser único por todas as implantações do aplicativo na instância do JBoss EAP 6. Por exemplo:

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

2. Configure o valor hibernate.ejb.entitymanager_factory_name como um nome único. Este nome deve ser único para todas as implantações do aplicativo na instância do JBoss EAP 6. Por exemplo:

   <property name="hibernate.ejb.entitymanager_factory_name" value="seam-booking.ear_PersistenceUnitName"/>
   

Procedimento 3.16. Modificação do arquivo persistence.xml para usar Infinispan

1. Configure Infinispan para um aplicativo JPA no JBoss EAP 6

   Esta é a forma como você especifica as propriedades para atingir a mesma configuração para um aplicativo JPA usando Infinispan no JBoss EAP 6:

   <property name="hibernate.cache.use_second_level_cache" value="true"/>
   

   Além disso, você precisa especificar um shared-cache-mode com um valor de ENABLE_SELECTIVE ou ALL conforme abaixo:
   • ENABLE_SELECTIVE é o valor padrão e recomendado. Isto significa que as entidades não estão armazenadas em cache, a não ser que você marque-as, explicitamente, como armazenáveis em cache.

     <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
     

   • ALL significa que as entidades são sempre armazenadas em cache, mesmo que você marque-as como não armazenáveis em cache.

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

2. Configure Infinispan para um aplicativo Hibernate native no JBoss EAP 6

   Esta é a forma como você pode especificar a mesma configuração para um aplicativo Hibernate nativo usando Infinispan com o JBoss EAP 6:

   <property name="hibernate.cache.region.factory_class"
        value="org.jboss.as.jpa.hibernate4.infinispan.InfinispanRegionFactory"/>
   <property name="hibernate.cache.infinispan.cachemanager"
        value="java:jboss/infinispan/container/hibernate"/>     
   <property name="hibernate.transaction.manager_lookup_class"
        value="org.hibernate.transaction.JBossTransactionManagerLookup"/>
   <property name="hibernate.cache.use_second_level_cache" value="true"/>
   
   

   Você deve adicionar também as seguintes dependências ao arquivo MANIFEST.MF:

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

Procedimento 3.17. É possível que tenha que executar uma ou mais das seguintes tarefas

1. Acesse o ValidatorFactory padrão

   O JBoss EAP 6 conecta um ValidatorFactory padrão ao contexto JNDI sob o nome java:comp/ValidatorFactory.

2. Compreenda a validação disparada pelo ciclo de vida

   Quando usado em combinação com o Hibernate Core 4, a validação baseada no ciclo de vida é automaticamente habilitada pelo Hibernate Core.
   1. A validação ocorre nas operações INSERT, UPDATE e DELETE de entidade.
   2. É possível 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
      • javax.persistence.validation.group.pre-remove.

      Os valores dessas propriedades são os nomes de classe inteiramente qualificados, separados por vírgula dos grupos a serem validados.
      Os grupos de validação são um novo recurso de especificação Bean Validation. Caso não queira tirar proveito das vantagens desse novo recurso, você não precisa fazer alterações quando migrar para o Hibernate Validator 4.
   3. É possível desativar a validação baseada no ciclo de vida configurando a propriedade javax.persistence.validation.mode como none. Outros valores válidos para esta propriedade são auto (padrão), callback e ddl.

3. Configure seu aplicativo para usar validação manual

   1. Caso queira controlar manualmente a validação, é possível criar um Validator segundo uma das seguintes maneiras:

      • Crie uma instância Validator a partir de ValidatorFactory usando o método getValidator().
      • Injete as instâncias do Validator em seu EJB, bean CDI ou qualquer outro recurso Java EE injetável.
   2. É possível usar o ValidatorContext devolvido pelo ValidatorFactory.usingContext() para personalizar a instância do seu Validador. Ao usar esta API, você pode configurar um MessageInterpolator, TraverableResolver e ConstraintValidatorFactory personalizados. Essas interfaces estão especificadas na especificação Bean Validation e são novas para o Hibernate Validator 4.

4. Modifique o código para usar as novas restrições do Bean Validation

   As novas restrições de validação de nível Bean exigem alterações de código, quando você migra para o Hibernate Validator 4.
   1. Para fazer a atualização para o Hibernate Validator 4, você precisa usar as restrições nos seguintes pacotes:

      • 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, é necessário importar a classe especificada e, em alguns casos, alterar o nome ou o tipo de parâmetro de restrição.

5. Use restrições personalizadas

   No Hibernate Validator 3, uma restrição personalizada necessitava de implementar a interface org.hibernate.validator.Validator. No Hibernate Validator 4, é necessário implementar 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 possui mais suporte no Hibernate Validator 4.

Procedimento 3.18. Criação de uma Ponte JMS

1. Configuração da Ponte no Servidor do JBoss EAP 5.x Fonte

   Para evitar conflitos nas classes entre as versões, você deve seguir as seguintes etapas para configurar a ponte JMS no JBoss EAP 5.x. Os nomes da ponte e do diretório SAR são arbitrários e podem ser alterados, caso prefira.
   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 no diretório EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/META-INF/. Ele deve conter informações semelhantes ao exemplo a seguir.

      <server>
         <loader-repository>
            com.example:archive=unique-archive-name
            <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
         </loader-repository> 
      
         <!-- JBoss EAP 6 JMS Provider --> 
         <mbean code="org.jboss.jms.jndi.JMSProviderLoader" name="jboss.messaging:service=JMSProviderLoader,name=EnterpriseApplicationPlatform6JMSProvider">
            <attribute name="ProviderName">EnterpriseApplicationPlatform6JMSProvider</attribute>
            <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
            <attribute name="FactoryRef">jms/RemoteConnectionFactory</attribute> 
            <attribute name="QueueFactoryRef">jms/RemoteConnectionFactory</attribute>  
            <attribute name="TopicFactoryRef">jms/RemoteConnectionFactory</attribute>      
            <attribute name="Properties">
               java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
               java.naming.provider.url=remote://EnterpriseApplicationPlatform6host:4447
               java.naming.security.principal=jbossuser
               java.naming.security.credentials=jbosspass
            </attribute>
         </mbean> 
      
         <mbean code="org.jboss.jms.server.bridge.BridgeService" name="jboss.jms:service=Bridge,name=MyBridgeName" xmbean-dd="xmdesc/Bridge-xmbean.xml">      
            <depends optional-attribute-name="SourceProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends>          
            <depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=EnterpriseApplicationPlatform6JMSProvider</depends>          
            <attribute name="SourceDestinationLookup">/queue/A</attribute>      
            <attribute name="TargetDestinationLookup">jms/queue/test</attribute>       
            <attribute name="QualityOfServiceMode">1</attribute>           
            <attribute name="MaxBatchSize">1</attribute>      
            <attribute name="MaxBatchTime">-1</attribute>           
            <attribute name="FailureRetryInterval">60000</attribute>      
            <attribute name="MaxRetries">-1</attribute>      
            <attribute name="AddMessageIDInHeader">false</attribute>
            <attribute name="TargetUsername">jbossuser</attribute>
            <attribute name="TargetPassword">jbosspass</attribute>
         </mbean>
      </server>
      
      

      Nota

      O elemento load-repository está presente para garantir que o SAR tenha um carregador de classe isolado. Além disso, observe que tanto a pesquisa JNDI e quanto a ponte "destino" incluem credenciais de segurança para o usuário "jbossuser" com a senha "jbosspass". Isto acontece pelo fato do JBoss EAP 6 ser protegido por padrão. O usuário nomeado "jbossuser" com a senha "jbosspass" foi criado em 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 da versão vigente na 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 EAP_HOME/bin/client/jboss-client.jar, pois as classes API javax entrarão em conflito com aquelas no JBoss EAP 5.x.

2. Configuração da Ponte no Servidor JBoss EAP 6 de Destino

   No JBoss EAP 6.1 e versões mais recentes, a ponte JMS pode ser usada para transferir as mensagens a partir de qualquer servidor compatível com o JMS 1.1. Uma vez que os recursos JMS fonte e destino são pesquisados usando JNDI, as classes de pesquisa JNDI do provedor do sistema de mensagem fonte, ou agente de mensagem, devem ser empacotadas em um módulo JBoss. As etapas a seguir usam o agente de mensagem fictício 'MyCustomMQ' como um exemplo.
   1. Criação do módulo JBoss para o provedor do sistema de mensagem.
      1. Crie uma estrutura de diretório sob EAP_HOME/modules/system/layers/base/ para o novo módulo. O subdiretório main/ conterá o cliente JARs e o arquivo module.xml. Segue abaixo um exemplo da estrutura do diretório criada para o provedor do sistema 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 do sistema de mensagem. Segue abaixo um exemplo do module.xml criado para o provedor do sistema 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>
         

      3. Copie os JARs do provedor do sistema de mensagem necessários para a pesquisa JNDI dos recursos fonte para o subdiretório main/ do módulo. A estrutura do diretório para o módulo MyCustomMQ deve parecer-se com o seguinte.

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

   2. Configuração da ponte JMS no subsistema messaging do servidor 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 um servidor autônomo, este é o arquivo EAP_HOME/standalone/configuration/standalone-full-ha.xml. Caso você esteja executando um domínio gerenciado, realize o backup de 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. Se as credenciais user e password estiverem especificadas, elas serão passadas como argumentos quando a conexão JMS for criada.
         Segue abaixo um exemplo do elemento jms-bridge configurado para o fornecedor do sistema 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>
         

         No exemplo acima, as propriedades JNDI são definidas no elemento context para source. Caso o elemento context esteja omitido, como no exemplo acima target, os recursos JMS serão pesquisados na instância local.

Procedimento 3.19. Antes de começar

1. Desligue o cliente e o servidor
2. Realize uma cópia de backup dos dados do JBoss Messaging. Os dados da mensagem são armazenados em um banco de dados em tabelas com o prefixo JBM_.

Procedimento 3.20. Alteração do seu provedor para HornetQ

1. Transferência de configurações

   Transfira as configurações existentes do JBoss Messaging para configuração do JBoss EAP 6. As configurações a seguir podem ser encontradas nos descritores de implantação localizados no servidor JBoss Messaging:
   • Configuração do Serviço de Fábricas de Conexões
     Esta configuração descreve as fábricas de conexões JMS implantadas com o servidor JBoss Messaging. O JBoss Messaging configura as fábricas de conexões em um arquivo nomeado connection-factories-service.xml, que está localizado no diretório de implantação do servidor do aplicativo.
   • Configuração de Destino
     Esta configuração descreve os tópicos e as filas JMS implantadas com o servidor JBoss Messaging. Por padrão, o JBoss Messaging configura os destinos em um arquivo nomeado destinations-service.xml que está localizado no diretório de implantação do servidor do aplicativo.
   • Configuração do Serviço de Ponte de Mensagens
     Esta configuração inclui os serviços de ponte implantados com o servidor JBoss Messaging. Nenhuma ponte é implantada por padrão, portanto o nome do arquivo de implantação varia, dependendo da instalação do seu JBoss Messaging.

2. Modificação do código do seu aplicativo

   Se o código do aplicativo usa o JMS padrão, não são necessárias alterações ao código. No entanto, se o aplicativo for conectar a um cluster, você deve revisar cuidadosamente a documentação HornetQ sobre a semântica do clustering. O clustering está fora do escopo da especificação JMS e HornetQ e JBoss Messaging adotaram abordagens bastante diferentes em suas respectivas implementações da funcionalidade do clustering.
   Caso o aplicativo utilize recursos específicos ao JBoss Messaging, você deve modificar o código para usar os recursos equivalentes disponíveis no HornetQ.
   Para mais informações sobre como configurar o sistema de mensagens com HornetQ, consulte Seção 3.2.7.5, “Configuração do Sistema de Mensagens com HornetQ”.

3. Migração de mensagens existentes

   Mova quaisquer mensagens do banco de dados do JBoss Messaging para o diário HornetQ usando a ponte JMS. As instruções para a configuração da ponte JMS podem ser encontradas aqui: Seção 3.2.7.2, “Configuração de uma Ponte JMS para a Migração de Mensagens JMS Existentes ao JBoss EAP 6”.

1. Inicie o JBoss EAP 6 com o clustering habilitado

   Para habilitar o clustering no JBoss EAP 5.x, era preciso iniciar as instâncias do seu servidor usando o perfil all ou alguma derivação disto, como por exemplo:

   $ EAP5_HOME/bin/run.sh -c all

   No JBoss EAP 6, o método para a habilitação do clustering depende se os servidores estão executando em um domínio gerenciado ou se são autônomos.

   1. Habilitação do clustering para os servidores executando em um domínio gerenciado

      Para habilitar o clustering para os servidores iniciados usando o controlador de domínio, atualize o seu domain.xml e designe um grupo de servidor para usar o perfil ha e o grupo de associação 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>

   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 como a seguir:

      $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME

2. Especifique o endereço vinculado

   No JBoss EAP 5.x, você normalmente indicaria o endereço vinculado usado para clustering utilizando o argumento da linha de comando -b, conforme abaixo:

   $ EAP5_HOME/bin/run.sh -c all -b 192.168.0.2

   O JBoss EAP 6 associa os soquetes às interfaces e aos endereços IP contidos nos elementos <interfaces> nos arquivos standalone.xml, domain.xml e host.xml. As configurações padrão que são enviadas junto com o JBoss EAP incluem duas configurações de interface:

   <interfaces>
       <interface name="management">
           <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
       </interface>
       <interface name="public">
          <inet-address value="${jboss.bind.address:127.0.0.1}"/>
       </interface>
   </interfaces>

   Essas configurações de interface usam os valores das propriedades do sistema jboss.bind.address.management e jboss.bind.address. Caso essas propriedades do sistema não sejam determinadas, o padrão 127.0.0.1 é usado para cada valor.
   O endereço vinculado também pode ser especificado como um argumento da linha de comando quando você inicia o servidor ou pode ser explicitamente definido dentro do arquivo de configuração do servidor JBoss EAP 6.
   • Especifique o argumento vinculado na linha de comando quando iniciar o servidor autônomo do JBoss EAP.
     Segue abaixo um exemplo de como especificar o endereço vinculado na linha de comando para um servidor autônomo:

     EAP_HOME/bin/standalone.sh -Djboss.bind.address=127.0.0.1

     Nota

     É possível usar o argumento -b, que é um atalho para -Djboss.bind.address=127.0.0.1:

     EAP_HOME/bin/standalone.sh -b=127.0.0.1

     O formato da sintaxe do JBoss EAP 5 ainda possui suporte também:

     EAP_HOME/bin/standalone.sh -b 127.0.0.1

     Observe que o argumento -b apenas altera a interface public. Isto não afeta a interface management.
   • Especifique o endereço vinculado no arquivo de configuração do servidor.
     Para os servidores executando em um domínio gerenciado, especifique os endereços vinculados no arquivo domain/configuration/host.xml. Para os servidores autônomos, especifique os endereços vinculados no arquivo standalone-ha.xml.
     No exemplo a seguir, a interface public é especificada como a interface padrão para todos os soquetes dentro do grupo de associação de soquete ha-sockets.

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

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

     Nota

     Caso o endereço vinculado seja especificado como um valor codificado, ao invés de uma propriedade do sistema no arquivo de configuração, não será possível substituí-lo por um argumento da linha de comando.

3. Configure jvmRoute para suportar mod_jk e mod_proxy

   No JBoss EAP 5, o servidor web jvmRoute foi configurado usando uma 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}">
   

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

4. Especifique a porta e o endereço multicast

   No JBoss EAP 5.x, você poderia especificar a porta e o endereço multicast usados para a comunicação intra-cluster utilizando os argumentos da linha de comando -u e -m, como a seguir:

   $ EAP5_HOME/bin/run.sh -c all -u 228.11.11.11 -m 45688

   No JBoss EAP 6, a porta e o endereço multicast usados para a comunicação intra-cluster são definidos pela associação de soquete referenciada pela pilha do protocolo JGroups relevante, como a seguir:

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

   <socket-binding-groups>
       <socket-binding-group name="ha-sockets" default-interface="public">
           <!-- ... -->
           <socket-binding name="jgroups-udp" port="55200" multicast-address="228.11.11.11" multicast-port="45688"/>
           <!-- ... -->
       </socket-binding-group>
   </socket-binding-groups>
   

   Se você preferir especificar a porta e o endereço multicast na linha de comando, você pode definir as portas e o endereço multicast como propriedades de sistema e, então, usar essas propriedades na linha de comando, quando você iniciar o servidor. No exemplo a seguir, jboss.mcast.addr é o nome da variável para o endereço multicast e 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}"/>
   

   Você pode, então, iniciar o seu servidor usando os seguintes argumentos da linha de comando:

   $ EAP_HOME/bin/domain.sh -Djboss.mcast.addr=228.11.11.11 -Djboss.mcast.port=45688

5. Utilize uma pilha de protocolo alternativa

   No JBoss EAP 5.x, você poderia manipular a pilha do protocolo padrão usada para todos os serviços de clustering utilizando a propriedade do sistema jboss.default.jgroups.stack.

   $ EAP5_HOME/bin/run.sh -c all -Djboss.default.jgroups.stack=tcp

   No JBoss EAP 6, a pilha do protocolo padrão é definida pelo subsistema JGroups dentro do domain.xml ou standalone-ha.xml:

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

6. Substitue a Replicação Buddy

   O JBoss EAP 5.x usava a JBoss Cache Buddy Replication para suprimir a replicação de dados em todas as instâncias em um cluster.
   No JBoss EAP 6, a Replicação Buddy foi substituída pelo cache distribuído do Infinispan, também conhecido como modo DIST. A distribuição é um modo de clustering poderoso que permite o Infinispan escalar linearmente à medida que mais servidores são adicionados ao cluster. Segue abaixo um exemplo de como configurar o servidor para usar o modo de cache DIST.
   1. Abra uma linha de comando e inicie o servidor com o Perfil HA ou o Perfil Completo. Por exemplo:

      EAP_HOME/bin/standalone.sh -c standalone-ha.xml

   2. Abra outra linha de comando e conecte-se ao Gerenciamento CLI.
      • Para o Linux, insire a seguinte linha de comando:

        $ EAP_HOME/bin/jboss-cli.sh --connect
        

      • Para o Windows, insire a seguinte linha de comando:

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

      Você deverá encontrar a seguinte resposta:

      Conectado ao controlador autônomo em localhost:9999

   3. Emita os seguintes comandos:

      /subsystem=infinispan/cache-container=web/:write-attribute(name=default-cache,value=dist)
      /subsystem=infinispan/cache-container=web/distributed-cache=dist/:write-attribute(name=owners,value=3)
      :reload
      

      Você deverá encontrar a seguinte resposta após cada comando:

      "outcome" => "success"
      

      Esses comandos modificam o elemento dist <distributed-cache> na configuração web <cache-container> no subsistema infinispan do arquivo standalone-ha.xml, como a seguir:

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

      Para mais informações, consulte o capítulo entitulado Clustering in Web Applications no guia Development Guide do JBoss EAP 6 localizado no Portal do Consumidor https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

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

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

   Segue abaixo um exemplo de um Service que está encapsulado com o decorador SingletonService a ser implantado como um serviço singleton. Um exemplo completo pode ser encontrado na seção início rápido cluster-ha-singleton que é enviada junto com o Red Hat JBoss Enterprise Application Platform 6. O início rápido contém todas as instruções para a construção e implantação do aplicativo.

   1. Criação de um serviço.

      A lista abaixo é um exemplo de um serviço:

      package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
      
      import java.util.Date;
      import java.util.concurrent.atomic.AtomicBoolean;
      
      import javax.naming.InitialContext;
      import javax.naming.NamingException;
      
      import org.jboss.logging.Logger;
      import org.jboss.msc.service.Service;
      import org.jboss.msc.service.ServiceName;
      import org.jboss.msc.service.StartContext;
      import org.jboss.msc.service.StartException;
      import org.jboss.msc.service.StopContext;
      
      
      /**
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      public class HATimerService implements Service<String> {
          private static final Logger LOGGER = Logger.getLogger(HATimerService.class);
          public static final ServiceName SINGLETON_SERVICE_NAME = ServiceName.JBOSS.append("quickstart", "ha", "singleton", "timer");
      
          /**
           * A flag whether the service is started.
           */
          private final AtomicBoolean started = new AtomicBoolean(false);
      
          /**
           * @return the name of the server node
           */
          public String getValue() throws IllegalStateException, IllegalArgumentException {
              LOGGER.infof("%s is %s at %s", HATimerService.class.getSimpleName(), (started.get() ? "started" : "not started"), System.getProperty("jboss.node.name"));
              return "";
          }
      
          public void start(StartContext arg0) throws StartException {
              if (!started.compareAndSet(false, true)) {
                  throw new StartException("The service is still started!");
              }
              LOGGER.info("Start HASingleton timer service '" + this.getClass().getName() + "'");
      
              final String node = System.getProperty("jboss.node.name");
              try {
                  InitialContext ic = new InitialContext();
                  ((Scheduler) ic.lookup("global/jboss-cluster-ha-singleton-service/SchedulerBean!org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.Scheduler")).initialize("HASingleton timer @" + node + " " + new Date());
              } catch (NamingException e) {
                  throw new StartException("Could not initialize timer", e);
              }
          }
      
          public void stop(StopContext arg0) {
              if (!started.compareAndSet(true, false)) {
                  LOGGER.warn("The service '" + this.getClass().getName() + "' is not active!");
              } else {
                  LOGGER.info("Stop HASingleton timer service '" + this.getClass().getName() + "'");
                  try {
                      InitialContext ic = new InitialContext();
                      ((Scheduler) ic.lookup("global/jboss-cluster-ha-singleton-service/SchedulerBean!org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.Scheduler")).stop();
                  } catch (NamingException e) {
                      LOGGER.error("Could not stop timer", e);
                  }
              }
          }
      }
      

   2. Criação de um ativador que instale Service como um singleton clusterizado.

      A lista abaixo é um exemplo de um ativador de Serviço que instala HATimerService como um serviço de singleton clusterizado:

      package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
      
      import org.jboss.as.clustering.singleton.SingletonService;
      import org.jboss.logging.Logger;
      import org.jboss.msc.service.DelegatingServiceContainer;
      import org.jboss.msc.service.ServiceActivator;
      import org.jboss.msc.service.ServiceActivatorContext;
      import org.jboss.msc.service.ServiceController;
      
      
      /**
       * Service activator that installs the HATimerService as a clustered singleton service
       * during deployment.
       *
       * @author Paul Ferraro
       */
      public class HATimerServiceActivator implements ServiceActivator {
          private final Logger log = Logger.getLogger(this.getClass());
      
          @Override
          public void activate(ServiceActivatorContext context) {
              log.info("HATimerService will be installed!");
      
              HATimerService service = new HATimerService();
              SingletonService<String> singleton = new SingletonService<String>(service, HATimerService.SINGLETON_SERVICE_NAME);
              /*
               * To pass a chain of election policies to the singleton, for example, 
               * to tell JGroups to prefer running the singleton on a node with a
               * particular name, uncomment the following line:
               */
              // singleton.setElectionPolicy(new PreferredSingletonElectionPolicy(new SimpleSingletonElectionPolicy(), new NamePreference("node2/cluster")));
      
              singleton.build(new DelegatingServiceContainer(context.getServiceTarget(), context.getServiceRegistry()))
                      .setInitialMode(ServiceController.Mode.ACTIVE)
                      .install()
              ;
          }
      }
      

      Nota

      O exemplo de código acima utiliza uma classe, org.jboss.as.clustering.singleton.SingletonService, que faz parte da API privada do JBoss EAP. Uma API pública estará disponível na versão EAP 7 e a classe privada será preterida, porém estas classes serão mantidas e estarão disponíveis durante o ciclo de lançamento do EAP 6.x.

   3. Criação de um Arquivo ServiceActivator

      Crie um arquivo nomeado org.jboss.msc.service.ServiceActivator no diretório do arquivo resources/META-INF/services/. Adicione uma linha contendo um nome inteiramente qualificado da classe ServiceActivator criada na etapa anterior.

      org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator 

   4. Criação de um bean Singleton que implementa um timer a ser usado como um timer singleton no cluster inteiro.

      Este bean Singleton não deve possuir uma interface remota e não deve haver referência à sua interface local por outro EJB em qualquer aplicativo. Isto evita uma pesquisa por parte de um cliente ou outro componente e garante que o SingletonService tenha controle total do Singleton.

      1. Criação da interface do Agendador

         package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
         
         /**
          * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
          */
         public interface Scheduler {
         
             void initialize(String info);
         
             void stop();
         
         }
         

      2. Criação de um bean do Singleton que implementa o timer do singleton amplo com cluster.

         package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
         
         import javax.annotation.Resource;
         import javax.ejb.ScheduleExpression;
         import javax.ejb.Singleton;
         import javax.ejb.Timeout;
         import javax.ejb.Timer;
         import javax.ejb.TimerConfig;
         import javax.ejb.TimerService;
         
         import org.jboss.logging.Logger;
         
         
         /**
          * A simple example to demonstrate a implementation of a cluster-wide singleton timer.
          *
          * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
          */
         @Singleton
         public class SchedulerBean implements Scheduler {
             private static Logger LOGGER = Logger.getLogger(SchedulerBean.class);
             @Resource
             private TimerService timerService;
         
             @Timeout
             public void scheduler(Timer timer) {
                 LOGGER.info("HASingletonTimer: Info=" + timer.getInfo());
             }
         
             @Override
             public void initialize(String info) {
                 ScheduleExpression sexpr = new ScheduleExpression();
                 // set schedule to every 10 seconds for demonstration
                 sexpr.hour("*").minute("*").second("0/10");
                 // persistent must be false because the timer is started by the HASingleton service
                 timerService.createCalendarTimer(sexpr, new TimerConfig(info, false));
             }
         
             @Override
             public void stop() {
                 LOGGER.info("Stop all existing HASingleton timers");
                 for (Timer timer : timerService.getTimers()) {
                     LOGGER.trace("Stop HASingleton timer: " + timer.getInfo());
                     timer.cancel();
                 }
             }
         }
         

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

   Para habilitar o clustering para os servidores autônomos, você deve iniciar cada servidor com o perfil HA, usando um nome de nó único e uma porta de deslocamento para cada instância.
   • Para o Linux, use a seguinte sintaxe de comando para iniciar os servidores:

     EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME -Djboss.socket.binding.port-offset=PORT_OFFSET

     Exemplo 3.3. Inicie múltiplos servidores autônomos no Linux

     $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=node1
     $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100

   • Para o Microsoft Windows, use a seguinte sintaxe de comando para iniciar os servidores:

     EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME -Djboss.socket.binding.port-offset=PORT_OFFSET

     Exemplo 3.4. Inicie múltiplos servidores autônomos no Microsoft Windows

     C:> EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=node1
     C:> EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100

   Nota

   Caso decida por não usar os argumentos da linha de comando, o arquivo standalone-ha.xml pode ser configurado para cada instância do servidor para vincular a uma interface separada.

3. Implante o aplicativo nos servidores

   O comando Maven a seguir implanta o aplicativo em um servidor autônomo executando nas portas padrões.

   mvn clean install jboss-as:deploy

   Para a implantação de servidores adicionais, passe o nome do servidor. Caso esteja em um host diferente, passe o nome do host e o número da porta na linha de comando:

   mvn clean package jboss-as:deploy -Djboss-as.hostname=localhost -Djboss-as.port=10099

   Consulte a seção início rápido cluster-ha-singleton, que é enviada junto com o JBoss EAP 6, para mais detalhes sobre a configuração e implantação do Maven.

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

1. Adicione as dependências do projeto necessárias

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

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

   A API do cliente EJB JBoss espera encontrar um arquivo na raiz do projeto nomeado jboss-ejb-client.properties que contenha a informação da conexão para o serviço JNDI. Adicione este arquivo ao diretório src/main/resources/ do seu projeto com o seguinte conteúdo.

   # In the following line, set SSL_ENABLED to true for SSL
   remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
   remote.connections=default
   # Uncomment the following line to set SSL_STARTTLS to true for SSL
   # remote.connection.default.connect.options.org.xnio.Options.SSL_STARTTLS=true
   remote.connection.default.host=localhost
   remote.connection.default.port = 4447
   remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
   # Add any of the following SASL options if required
   # remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
   # remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false
   # remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
   

   Altere a porta e o nome do host para coincidir com o seu servidor. 4447 é o número de porta padrão. Para uma conexão segura, configure a linha SSL_ENABLED como true e remova os comentários da linha SSL_STARTTLS. A interface remota no contêiner suporta as conexões seguras e não seguras usando a mesma porta.

3. Adicione dependências para as interfaces comerciais remotas

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

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

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

1. Maneje as exceções verificadas

   Dois dos métodos usados nos códigos a seguir (InitialContext() e lookup()) possuem uma exceção verificada do tipo javax.naming.NamingException. Essas chamadas de método devem estar inseridas em um bloco de tentativa/captura que capture NamingException ou em um método que seja declarado para lançar NamingException. O início rápido ejb-remote utiliza a segunda técnica.

2. Crie um Contexto JNDI

   Um objeto do Contexto JNDI fornece o mecanismo para solicitar recursos do servidor. Crie um contexto JNDI usando o seguinte código:

   final Hashtable jndiProperties = new Hashtable();
   jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
   final Context context = new InitialContext(jndiProperties);

   As propriedades de conexão para o serviço JNDI são lidas a partir do arquivo jboss-ejb-client.properties.

3. Use o método lookup() do Contexto JNDI para obter um proxy bean

   Invoque o método lookup() do proxy bean e passe-o o nome JNDI do bean de sessão que você necessita. Isto retornará um objeto que deve ser convertido para o tipo da interface comercial remota que contém os métodos que você deseja invocar.

   
   final RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
       "ejb:/jboss-ejb-remote-server-side//CalculatorBean!" + 
       RemoteCalculator.class.getName());
   

   Os nomes JNDI de bean de sessão são definidos usando uma sintaxe especial. Consulte Seção 3.2.10.3, “Referência de Nomeação JNDI EJB ” para mais informações.

4. Invocação de Métodos

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

   O bean proxy passa a solicitação de invocação do método para o bean de sessão no servidor, onde é executado. O resultado é retornado ao bean proxy que, então, o retorna ao chamador. A comunicação entre o bean proxy e o bean de sessão remoto é transparente ao chamador.

Procedimento 3.25. Migração dos Arquivos Seam 2.2

1. Atualize a configuração da fonte de dados

   Alguns exemplos do Seam 2.2 usam a fonte de dados JDBC padrão nomeada java:/ExampleDS. Essa fonte de dados padrão foi alterada no JBoss EAP 6 para java:jboss/datasources/ExampleDS. Caso seu aplicativo utilize o banco de dados do exemplo, você pode realizar uma das seguintes opções:

   • Se você quiser usar o banco de dados do exemplo que é enviado junto com 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 do exemplo:

     <!-- <jta-data-source>java:/ExampleDS</jta-data-source> -->
     <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>

   • Caso você prefira manter o seu 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 a sua alteração seja efetivada ao reiniciar o servidor.
     A seguinte definição é uma cópia da fonte de dados HSQL padrão definida no JBoss EAP 6:

     <datasource name="ExampleDS" jndi-name="java:/ExampleDS" enabled="true" jta="true" use-java-context="true" use-ccm="true">
        <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
        <driver>h2</driver>
        <security>
           <user-name>sa</user-name>
           <password>sa</password>
        </security>
     </datasource>

   • Você pode também adicionar a definição da fonte de dados usando a interface da linha de comando do Gerenciamento CLI. Segue abaixo um exemplo da sintaxe que você deve usar para adicionar uma fonte de dados. O "\" no final da linha indica a continuação do comando na linha seguinte.

     Exemplo 3.5. Exemplo da sintaxe para a 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
     

   Consulte Seção 3.1.6.2, “Atualização da Configuração da DataSource” para mais informações sobre como configurar uma fonte de dados.

2. Adicione quaisquer dependências necessárias

   Já que os aplicativos Seam 2.2 utilizam JSF 1.2, você precisa adicionar dependências para os módulos JSF 1.2 e excluir os módulos JSF 2.0. Para realizar isto, 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>

   Se o seu aplicativo utiliza estruturas de registro em log de terceiros, você precisa adicionar essas dependências conforme descrito aqui: Seção 3.1.4.1, “Modificação das Dependências de Registro em Log”.

3. Se o seu aplicativo utilza Hibernate 3.x, tente executar primeiro o aplicativo usando as bibliotecas do Hibernate 4

   Se o seu aplicativo não utiliza o Contexto de Persistência Gerenciado Seam, a busca Hibernate, a validação ou quaisquer outros recursos que mudaram com o Hibernate 4, é possível que consiga executar com as bibliotecas do Hibernate 4. No entanto, se você encontrar ClassNotFoundExceptions ou ClassCastExceptions que apontam para as classes Hibernate, ou ver erros semelhantes aos seguintes, é possível que tenha que seguir as instruções da próxima etapa e modificar o seu aplicativo para usar as 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
   

4. Copie os arquivos dependentes das estruturas externas ou de outras localizações

   Se o seu aplicativo utiliza Hibernate 3.x e você não consegue usar Hibernate 4 no seu aplicativo com sucesso, você precisará copiar os JARs do Hibernate 3-x no diretório /lib e excluir o módulo Hibernate na seção de implantações de META-INF/jboss-deployment-structure.xml, como a seguir:

   <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
    <deployment>
      <exclusions>
        <module name="org.hibernate"/>
      </exclusions>
    <deployment>
   </jboss-deployment-structure>

   Você deve tomar algumas medidas adicionais quando agrupar Hibernate 3.x ao seu aplicativo. Consulte Seção 3.2.2.2, “Configuração das Alterações para os Aplicativos que Utilizam Hibernate e JPA” para mais informações.

5. Depure e resolva os erros JNDI do Seam 2.2

   Ao migrar o aplicativo Seam 2.2, você pode encontrar erros javax.naming.NameNotFoundException no log, como a seguir:

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

   Se você não deseja modificar as pesquisas JNDI através do código, você pode modificar o arquivo components.xml do aplicativo, como a seguir:

   1. Substitua o elemento core-init existente

      Primeiro, você precisa substituir o elemento core-init existente, como a seguir:

      <!-- <core:init jndi-pattern="jboss-seam-booking/#{ejbName}/local" debug="true" distributable="false"/>   -->
      <core:init debug="true" distributable="false"/>
      

   2. Localize as mensagens INFO associadas ao JNDI no log do servidor

      A seguir, localize as mensagens INFO associadas ao JNDI que estão impressas no log do servidor quando o aplicativo é implantado. As mensages vinculadas ao 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
      

   3. Adicione os elementos do componente

      Para cada mensagem INFO vinculada ao JNDI no log, 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" />

   Para mais informações sobre como depurar e resolver problemas de migração, consulte Seção 4.2.1, “Depuração e Solução de Problemas de Migração”.
   Para uma lista de problemas de migração conhecidos com os arquivos Seam 2, consulte Seção 3.2.13.2, “Problemas de Migração do Arquivo Seam 2.2 ”.