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 o log em registro, 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 de 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 rodagem e libera o desenvolvedor da tarefa de adicionar explicitamente as dependências. Para maiores detalhes de como e quando essas dependências são adicionadas, refira-se ao Implicit Module Dependencies no capítulo nomeado Class Loading and Modules no Development Guide do JBoss Enterprise Application Plataform 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 faltantes resultam em erros de implantação ou do período de rodagem. 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 ao Overview of Class Loading and Modules no capítulo chamado Class Loading and Module no Development Guide do JBoss Enterprise Application Plataform 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
      
      

   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>
      
      

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.
        • Insira a seguinte linha de comando para o Linux:

          $ EAP_HOME/bin/jboss-cli.sh --connect
          $ Connected to standalone controller at localhost:9999
          

        • Insira a seguinte linha de comando para o Windows:

          C:\>EAP_HOME\bin\jboss-cli.bat --connect
          C:\> Connected to standalone controller at 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 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 storage 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>
        
        

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

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 Enterprise Application Plataform 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>
   
   

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

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
   

   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 carregados com a 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 jar EJB com 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 permiti-las acessar-se 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>
   

   Por default, isto é configurado para falso, permitindo que as sub-implantações vejam as classes pertencentes a demais sub-implantações com o EAR.
   Para maiores informações sobre o carregamento da classe, refira-se ao capítulo Class Loading and Modules no Development Guide para o JBoss Enterprise Application Plataform 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 abaixo 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 Enterprise Application Plataform 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 storage 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/

      Qualquer driver compatível com JDBC 4.0 é automaticamente reconhecido e instalado no sistema pelo nome e versão. Um JAR compatível com 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

      • Crie um arquivo java.sql.Driver no diretório de implantação. Para uma instância do JBoss Enterprise Application Plataform 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 storage 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 storage 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>
           
           
           

           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/

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

           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/

      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 storage 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"/>
      

      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>
      
      

   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 a sua alteração ser persistente 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>
      
      

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, “Sintaxe de Nomeação JNDI Portável”

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 Enterprise Application Plataform 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>
   
   

   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 Enterprise Application Plataform 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 Enterprise Application Plataform 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 Enterprise Application Plataform 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.

   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

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 Enterprise Application Plataform. Por exemplo:

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

2. Determine o valor hibernate.ejb.entitymanager_factory_name a este nome único. Este nome deve ser único por todas as implantações do aplicativo na instância do JBoss Enterprise Application Plataform. Por exemplo:

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

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

1. Configuração Infinispan para o aplicativo JPA no JBoss Enterprise Application Plataform 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 Enterprise Application Plataform 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:
   • O ENABLE_SELECTIVE é o default e valor recomendado. Isto significa que as entidades não possuem cache a não que você marque-as como com cache.

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

   • ALL significa que as entidades sempre possuem cache mesmo que você as marque sem cache.

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

2. Configure o Infinispan para o aplicativo Hibernate native no JBoss Enterprise Application Plataform 6

   Esta é a forma de como você especifica a mesma configuração para o aplicativo Hibernate native usando o Infinispan com o JBoss Enterprise Application Plataform 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 o seguinte ao arquivo MANIFEST.MF:

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

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

1. Acesso ao ValidatorFactory default

   O JBoss Enterprise Application Plataform 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 ativado 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. Configuração do JMS Bridge

1. Crie um subdiretório no diretório de implantação do JBoss Enterprise Application Plataform 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 Enterprise Application Platform 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 <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 Enterprise 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 Enterprise Application Plataform 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 Enterprise Application Plataform 5.x.

Procedimento 3.20. 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.21. Altere seu provedor para o HornetQ

1. Transfira configurações

   A transferência das configurações do JBoss Messaging à configuração do JBoss Enterprise Application Plataform. 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 da 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.6.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 da ponte JMS podem ser encontrados na: Seção 3.2.6.2, “Configuração do JMS Bridge para Migração de JMS Messages Existentes ao JBoss Enterprise Application Plataform 6”.

Procedimento 3.22. 

1. Inicie o JBoss Enterprise Application Plataform 6 com o clustering ativado

   Para ativar o clustering no JBoss Enterprise Application Plataform 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 Enterprise Application Plataform 6, o método para ativação do clustering depende dos servidores serem autônomos ou serem executados num storage domain.

   1. Ativação do cluster para servidores rodando num storage domain

      Para ativar o clustering para servidores iniciados usando o controlador do domain, atualize o seu domain.xml e determine um grupo de servidor para uso do seu perfil ha e grupo binding de socket 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. Ativação do cluster para servidores autônomos

      Para ativar 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 Enterprise Application Plataform 5.x, você normalmente indicaria o endereço bind usado para o clustering usando o argumento da linha de comando -b parecido com: $ EAP_HOME/bin/run.sh -c all -b 192.168.0.2
   No JBoss Enteprise Application Plataform 6, os endereços bind são claramente definidos pelos bindings de sockets relevantes com os arquivos da configuração do JBoss Enterprise Application Plataform 6. Para os servidores iniciados usando o controlador do domain, 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>
   

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

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

3. Configure o jvmRoute para suportar o mod_jk e mod_proxy

   No JBoss Enterprise Application Plataform 5, o servidor da web jvmRoute foi configurado usando a propriedade no arquivo server.xml. No JBoss Enterprise Application Plataform 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 Management Console.

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

   No JBoss Enterprise Application Plataform 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 Enterprise Application Plataform 6, o endereço e porta multicast usados para a comunicação do cluster são definidos pelo socket-binding referenciado pela pilha do protocolo JGroups relevante, conforme abaixo:

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

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

   Caso você preferir especificar o endereço multicast e a porta na linha de comando, você pode definir o endereço multicast e as portas como propriedades de sistema e usá-las na linha de comando quando você inciar 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}"/>
   
   

   Você pode inciar 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 Enterprise Application Plataform 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 Enterprise Application Plataform 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>
   

Procedimento 3.23. 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() + "'");
              }
          }
      }
      
      

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

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

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

2. Inicie cada instância do JBoss Enterprise Application Plataform 6 com o clustering habilitado.

   O método de ativação com cluster depende se os servidores forem autônomos ou rodando num storage domain.

   1. Habilite o clustering para servidores executando num storage 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 controlador de domain.

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

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

           Nesta amostra, assuma que o endereço IP do controlador de domain é 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
             $ Connected to domain controller at 192.168.0.14
             

           • Insira a seguinte linha de comando para o Windows:

             C:\>EAP_HOME\bin\jboss-cli.bat --connect --controller=192.168.0.14
             C:\> Connected to domain controller at 192.168.0.14
             

        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
           }
           

        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
           }
           

        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
           }
           

        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
           }
           

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

        1. Interrompa o servidor do JBoss Enterprise Application Plataform.

           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 binding de socket 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>
           
           

        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>
           
           

        4. Inicie o servidor.

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

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

      Para ativar 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 Linux
      • Digite EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME para 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 rodando 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.24. 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.

   remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
   
   remote.connections=default
   
   remote.connection.default.host=localhost
   remote.connection.default.port = 4447
   remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
   
   

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

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

1. Manuseia as 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. A inicialização rápida ejb-remote 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);
   

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

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

   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.26. Execute o EJB 2.x no JBoss Enterprise Application Plataform 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, “Amostras do JNDI Namespaces nas Versões Anteriores e como elas são especificadas no JBoss Enterprise Application Plataform.”.

2. Substitua os Interceptores do JBoss AOP

   O JBoss AOP (Aspect Oriented Programming - Programação Orientada do Aspecto) não está mais incluído no JBoss Enterprise Application Plataform 6. Nas liberações anteriores, o JBoss AOP era usado pelo contêiner EJB. No entanto, no JBoss Enterprise Application Plataform 6, o contêiner EJB usa um novo mecanismo. Caso o seu aplicativo usar o JBoss AOP, você precisará modificar o seu código do aplicativo como abaixo.

   • As configurações EJB3 padrões que eram realizadas no arquivo ejb3-interceptors-aop.xml são agora realizadas no arquivo de configuração. Isto é um arquivo standalone/configuration/standalone-full.xml para o servidor autônomo. Caso você esteja executando o seu servidor num storage domain, este é o arquivo domain/configuration/domain.xml.
   • Os aplicativos que integram os interceptores na camada EJB devem ser redesignados para uso dos interceptores EJB3 e CDI. Os interceptores ao lado do servidor podem ser alterados para os interceptores EJB3.

3. Modificação do Descritor do Arquivo jboss-web.xml

   Modifique o <jndi-name> para cada <ejb-ref> usar o novo formato de observação inteiramente qualificado JNDI.

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

5. 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 Enterprise Application Plataform 6 com o perfil completo.

Procedimento 3.27. 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 Enterprise Application Plataform 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 Enterprise Application Plataform 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>
     

   • 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 a sua alteração ser persistente na iniciação do servidor.
     A seguinte definição é uma cópia da fonte de dados HSQL default definida no JBoss Enterprise Application Plataform 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 jbossadmin. 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
     

   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>
   

   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
   

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>
   

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

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

   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
      

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

   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.11.2, “Problemas de Migração do Seam 2.2 Archive”.