Capítulo 3. Migre seu Aplicativo


3.1. Alterações Requeridas para a maioria dos Aplicativos

3.1.1. Revisão das Alterações Requeridas para a Maioria dos Aplicativos

As alterações do carregamento da classe e configuração no JBoss EAP 6 irão impactar em quase todos os aplicativos. O JBoss EAP 6 usa também uma nova sintaxe de nomeação JNDI portátil default. Essas alterações irão impactar na maioria dos aplicativos, por isso sugerimos primeiramente a revisão da seguinte informação antes de você migrar seu aplicativo.

3.1.2. Alterações do Carregamento de Classe

O carregamento da classe modular é uma mudança significativa no JBoss EAP 6 e irá impactar em quase todos os aplicativos. Revise a seguinte informação primeiramente quando você migrar o seu aplicativo.
  1. Primeiro, busque pelo empacotamento de seu aplicativo e suas dependências. Consulte a Seção 3.1.2.3, “Atualização das Dependências do Aplicativo devido às Alterações do Carregamento da Classe” para maiores informações.
  2. Caso o seu aplicativo não efetuar a conexão, você precisará especificar as dependências de módulo corretas. Consulte a Seção 3.1.4.1, “Modificação das Dependências de Registro em Log” para maiores informações
  3. Devido às alterações de carregamento de classe modular, você talvez precise alterar a estrutura do empacotamento de seu EAR ou WAR. Consulte a Seção 3.1.5.1, “Modificação do Empacotamento dos EARS e WARs” para maiores informações.

3.1.2.2. Compreendendo as Dependências do Módulo

Sumário

Um módulo é apenas apto a acessar suas próprias classes e as classes de qualquer módulo que possui uma dependência explícita ou implícita.

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

  1. Compreendendo as dependências implícitas

    Os implantadores com o servidor implicitamente automatizado, adicionam algumas das dependências do módulo comumente usadas, como por exemplo javax.api e sun.jdk. Isto faz as classes visíveis à implantação no período de execução e libera o desenvolvedor da tarefa de adicionar explicitamente as dependências. Para maiores detalhes de como e quando essas dependências implícitas são adicionadas, refira-se às Dependências de Módulo Implícitas no capítulo nomeado Carregamento de Classe e Módulos do Guia de Desenvolvimento do JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.
  2. Compreendendo as dependências explícitas

    Para outras classes, os módulos devem ser especificados explicitamente ou as dependências ausentes resultam em erros de implantação ou do período de execução. Caso falte uma dependência, você verá traços ClassNotFoundExceptions ou NoClassDefFoundErrors no log do servidor. Caso mais de um módulo efetuar o carregamento ao mesmo JAR ou um módulo efetuar o carregamento numa classe que estende a classe com carregamento por um módulo diferente, você verá traços ClassCastExceptions no log do servidor. Para especificar as dependências, modifique o MANIFEST.MF ou crie um jboss-deployment-structure.xml do arquivo do descritor de implantação específico do JBoss. Para maiores informações sobre as dependências do módulo, refira-se à Visão Geral de Carregamento de Classe e Módulo no capítulo chamado Carregamento de Classe e Módulo no Guia de Desenvolvimento do JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.
Sumário

O carregamento de classe no JBoss EAP 6 é consideravelmente diferente do que as versões anteriores do JBoss EAP. O carregamento de classe é agora baseado no projeto de Módulos do JBoss. Ao invés de um único carregador, o carregador de classe hierárquico que carrega todos os JARS num caminho de classe plano, cada biblioteca torna-se um módulo que apenas conecta os módulos extras dos quais ela depende. As implantações no JBoss EAP 6 são módulos e não precisam ter acesso às classes que são definidas nos JARs de um servidor de aplicativo a não ser que uma dependência explícita seja definida nessa classe. Algumas das dependências do módulo definidas pelo servidor do aplicativo são configuradas automaticamente. Por exemplo: caso você esteja implantando um aplicativo Java EE, uma dependência no Java EE API é adicionada automaticamente ou implicitamente. Para uma lista de dependências adicionadas automaticamente pelo servidor, refira-se às Dependências de Módulo Implícitas no capítulo nomeado Carregamento de Classe e Módulos no Guia de Desenvolvimento para o JBoss Enterprise Application Plataform 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

Tarefas

Quando você migrar seu aplicativo ao JBoss EAP 6, você pode precisar executar uma ou mais das seguintes tarefas devido às alterações do carregamento de classe modular:

3.1.3. Alterações do Arquivo de Configuração

Sumário

Devido à alteração no JBoss EAP 6 para uso do carregamento da classe modular, você talvez precise criar ou modificar um ou mais arquivos para adicionar dependências ou para prevenir dependências automáticas de serem carregadas. Para maiores informações sobre o carregamento de classe e a procedência do carregamento de classe, refira-se ao capítulo nomeado Carregamento de Classe e Módulos no Guia de Desenvolvimento para o JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

Os seguintes arquivos são usados para controlar o carregamento da classe no JBoss EAP 6.
jboss-web.xml
Caso tenha definido um elemento <class-loading> no arquivo jboss-web.xml, você precisará removê-lo. O comportamento que isto causou no JBoss EAP 5 é agora o comportamento do carregamento da classe default no JBoss EAP 6, portanto não é mais necessário. Caso você não remova mais esse elemento, você verá um ParseError e XMLStreamException no seu log do servidor.
Segue abaixo uma amostra do elemento <class-loading> no arquivo jboss-web.xml que encontra-se comentado.
<!DOCTYPE jboss-web PUBLIC
    "-//JBoss//DTD Web Application 4.2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss-web_4_2.dtd">
<jboss-web>  
<!-- 
    <class-loading java2ClassLoadingCompliance="false">
        <loader-repository>
            seam.jboss.org:loader=MyApplication
            <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
        </loader-repository>
    </class-loading>
 -->
 </jboss-web>


Copy to Clipboard Toggle word wrap
MANIFEST.MF
Editado manualmente
Dependendo de quais componentes ou módulos o seu aplicativo usa, você precisa adicionar uma ou mais dependências a este arquivo. Você pode adicioná-las tanto como Dependencies ou como entradas Class-Path.
Segue abaixo uma amostra MANIFEST.MF editada por um desenvolvedor:
Manifest-Version: 1.0
Dependencies: org.jboss.logmanager
Class-Path: OrderManagerEJB.jar

Copy to Clipboard Toggle word wrap
Caso você modifique esse arquivo, certifique-se de incluir um caractere com linha nova no final do arquivo.
Usando o Maven
Caso você use o Maven, você precisa modificar o seu arquivo pom.xml para gerar as dependências para o arquivo MANIFEST.MF. Caso seu aplicativo usar o EJB 3.0, você pode possuir uma seção no arquivo pom.xml parecida com o seguinte:
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-ejb-plugin</artifactId>
    <configuration>
        <ejbVersion>3.0</ejbVersion>
    </configuration>
</plugin>

Copy to Clipboard Toggle word wrap
Caso o código EJB 3.0 usar o org.apache.commons.log, você precisará daquela dependência no arquivo MANIFEST.MF. Com o objetivo de gerar aquela dependência, adicione o elemento <plugin> ao arquivo pom.xml, conforme abaixo:
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-ejb-plugin</artifactId>
    <configuration>
        <ejbVersion>3.0</ejbVersion>
        <archive>
            <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
        </archive>
    </configuration>
</plugin>

Copy to Clipboard Toggle word wrap
Na amostra acima, o arquivo src/main/resources/META-INF/MANIFEST.MF precisa apenas conter a entrada da dependência:
Dependencies: org.apache.commons.logging
Copy to Clipboard Toggle word wrap
O Maven gerará o arquivo MANIFEST.MF completo:
Manifest-Version: 1.0
Dependencies: org.apache.commons.logging
Copy to Clipboard Toggle word wrap
jboss-deployment-structure.xml
Esse arquivo é um descritor de implantação específico do JBoss que pode ser usado para controlar o carregamento da classe de forma granulada. Assim como o MANIFEST.MF, esse arquivo pode ser usado para adicionar dependência. Isto pode também prevenir que dependências automáticas sejam adicionadas, definir módulos adicionais, alterar o comportamento de carregamento da classe isolado da implantação EAR e adicionar raízes de recurso adicional ao módulo.
Segue abaixo uma amostra do arquivo jboss-deployment-structure.xml que adiciona uma dependência para o módulo JSF 1.2 e previne o carregamento automático do módulo JSF 2.0.
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
  <deployment>
      <dependencies>
        <module name="javax.faces.api" slot="1.2" export="true"/>
              <module name="com.sun.jsf-impl" slot="1.2" export="true"/>
      </dependencies>
  </deployment>
  <sub-deployment name="jboss-seam-booking.war">
    <exclusions>
        <module name="javax.faces.api" slot="main"/>
              <module name="com.sun.jsf-impl" slot="main"/>
      </exclusions>
      <dependencies>
        <module name="javax.faces.api" slot="1.2"/>
              <module name="com.sun.jsf-impl" slot="1.2"/>
      </dependencies>
  </sub-deployment>
</jboss-deployment-structure>
Copy to Clipboard Toggle word wrap
Consulte a Seção 3.1.3.2, “jboss-deployment-structure.xml” para informações adicionais sobre este arquivo.
application.xml
Nas versões anteriores do JBoss EAP, você controlou a ordem das implantações com um EAR usando o arquivo jboss-app.xml. Isto não é mais a mesma situação. O Java EE6 spec fornece o elemento <initialize-in-order> no application.xml que permite o controle da ordem pela qual os módulos do Java EE com um EAR são implantados.
Na maioria das vezes, você não precisa especificar a ordem da implantação. Caso o seu aplicativo use injeções de dependência e referências de recurso para referenciar componentes em módulos externos, o elemento <initialize-in-order> não é requerido na maioria das vezes, uma vez que o servidor do aplicativo está apto a determinar implicitamente a maneira correta e ideal de ordenar os componentes.
Vamos assumir que você possui um aplicativo que contém um myBeans.jar e um myApp.war com um myApp.ear. Um servlet no myApp.war@EJB injeta um bean do myBeans.jar. Neste caso, o servidor do aplicativo possui um conhecimento apropriado para certificar-se de que o componente EJB está disponível antes do servlet ser iniciado e você não precisará usar o elemento <initialize-in-order>.
No entanto, caso o servlet usar referências remotas de estilo de pesquisa JNDI de legacia como o seguinte para acesso ao bean, você poderá especificar a ordem do módulo.
init() {
  Context ctx = new InitialContext();
  ctx.lookup("TheBeanInMyBeansModule");
}
Copy to Clipboard Toggle word wrap
Neste caso, o servidor não está apto a determinar que o componente EJB está no myBeans.jar e você precisa reforçar que os componentes no myBeans.jar são inicializados e ativados antes dos componentes no myApp.war. Para isto, você configura o elemento <initialize-in-order> para true e especifica a ordem dos módulos myBeans.jar e myApp.war no arquivo application.xml.
Segue abaixo uma amostra que usa o elemento <initialize-in-order> para controlar a ordem de implantação. O myBeans.jar é implantado antes do arquivo myApp.war.
<application xmlns="http://java.sun.com/xml/ns/javaee" 
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="6"
             xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
             http://java.sun.com/xml/ns/javaee/application_6.xsd">
    <application-name>myApp</application-name>
    <initialize-in-order>true</initialize-in-order>
    <module>
        <ejb>myBeans.jar</ejb>
    </module>
    <module>
        <web>
            <web-uri>myApp.war</web-uri>
            <context-root>myApp</context-root>
        </web>
    </module>
</application>
Copy to Clipboard Toggle word wrap
O esquema para o arquivo application.xml pode ser encontrado no http://java.sun.com/xml/ns/javaee/application_6.xsd.

Nota

Você deve estar ciente que a configuração do elemento <initialize-in-order> para true reduz a velocidade da implantação. É preferível definir as dependências de maneira apropriada usando injeções de dependência ou referências de recurso, uma vez que isto permite o contêiner maior flexibilidade na implantações ideais.
jboss-ejb3.xml
O descritor da implantação jboss-ejb3.xml substitui o descritor da implantaçã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.
login-config.xml
O arquivo login-config.xml não é mais usado para a configuração de segurança. A segurança é agora configurada no elemento <security-domain> no arquivo de configuração do servidor. Para um servidor autônomo, este é o arquivo standalone/configuration/standalone.xml. Caso você esteja executando o seu servidor num managed domain, esse é o arquivo domain/configuration/domain.xml.

3.1.3.2. jboss-deployment-structure.xml

O jboss-deployment-structure.xml é um novo descritor de implantação opcional para o JBoss EAP 6. Este descritor de implantação fornece controle sobre o carregamento da classe na implantação.
O esquema para este descritor de implantação é o EAP_HOME/docs/schema/jboss-deployment-structure-1_2.xsd

3.1.3.3. Recursos de Pacote para o Novo Sistema de Carregamento de Classe Modular

Sumário

Nas versões anteriores do JBoss EAP, todos os recursos dentro do diretório WEB-INF/ foram adicionados ao caminho de classe WAR. No JBoss EAP 6, os artefatos do aplicativo da web são apenas carregados a partir dos diretórios WEB-INF/classes e WEB-INF/lib. A falha dos artefatos do aplicativo do pacote nas localizações especificadas pode resultar no ClassNotFoundException, NoClassDefError, ou outros erros do período de execução.

Para resolver esses erros de carregamento da classe, você deverá modificar a estrutura de seu arquivo do aplicativo ou definir um módulo personalizado.

Modificação do Empacotamento de Recurso
Para disponibilizar os recursos apenas para o aplicativo, você deve empacotar os arquivos de propriedades, JARs e outros artefatos com WAR, movendo-os ao diretório WEB-INF/classes/ ou WEB-INF/lib/. Essa abordagem está descrita com maiores detalhes na: Seção 3.1.3.4, “Alteração da Localização das Propriedades ResourceBundle”
Criação de um Módulo Personalizado
Caso você deseje disponibilizar recursos personalizados a todos os aplicativos executando no servidor do JBoss EAP 6, você deve criar um modelo personalizado. Esta abordagem está descrita em maiores detalhes na: Seção 3.1.3.5, “Criação de um Módulo Personalizado”

3.1.3.4. Alteração da Localização das Propriedades ResourceBundle

Sumário

Nas versões anteriores do JBoss EAP, o diretório EAP_HOME/server/SERVER_NAME/conf/ estava no classpath e disponível ao aplicativo. Para disponibilizar as propriedades ao caminho da classe do aplicativo no JBoss EAP 6, você deve empacotá-las com seu aplicativo.

Procedimento 3.2. 

  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.

3.1.3.5. Criação de um Módulo Personalizado

O seguinte procedimento descreve como criar um módulo personalizado com o objetivo de criar arquivos de propriedades e outros recursos disponíveis a todos os aplicativos sendo executados no servidor do JBoss EAP.

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

  1. Crie e preencha a estrutura do diretório module/.
    1. Crie uma estrutura de diretório sob o diretório EAP_HOME/module para conter os arquivos e JARs. Por exemplo:
      $ cd EAP_HOME/modules/ $ mkdir -p myorg-conf/main/properties
      
      
      Copy to Clipboard Toggle word wrap
    2. Mova os arquivos de propriedades ao diretório EAP_HOME/modules/myorg-conf/main/properties/ criado na etapa anterior.
    3. Crie um arquivo module.xml no diretório EAP_HOME/modules/myorg-conf/main/ contendo o seguinte XML:
      <module xmlns="urn:jboss:module:1.1" name="myorg-conf">
          <resources>
              <resource-root path="properties"/>
          </resources>
      </module>
      
      
      Copy to Clipboard Toggle word wrap
  2. Modifique o subsistema ee no arquivo de configuração do servidor. Você pode usar o JBoss CLI ou pode editar manualmente o arquivo.
    • Siga as seguintes etapas para modificar o arquivo de configuração do servidor usando o JBoss CLI.
      1. Inicie o servidor e conecte-se ao Management CLI.
        • Insira a seguinte linha de comando para o Linux:
          $ EAP_HOME/bin/jboss-cli.sh --connect
          
          Copy to Clipboard Toggle word wrap
        • Insira a seguinte linha de comando para o Windows:
          C:\>EAP_HOME\bin\jboss-cli.bat --connect
          
          Copy to Clipboard Toggle word wrap
        Você deverá observar a seguinte resposta:
        Conectado ao controlador autônomo no localhost:9999
        Copy to Clipboard Toggle word wrap
      2. Para criar o elemento myorg-conf<global-modules> no subsistema ee, digite o seguinte na linha de comando:
        /subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])
        
        Copy to Clipboard Toggle word wrap
        Você deverá ver o seguinte resultado:
        {"outcome" => "success"}
        
        Copy to Clipboard Toggle word wrap
    • Siga essas etapas caso prefira editar manualmente o arquivo da configuração do servidor.
      1. Interrompa o servidor e abra o arquivo de configuração do servidor num editor de texto. Caso você esteja executando um servidor autônomo, este é o arquivo EAP_HOME/standalone/configuration/standalone.xml ou caso esteja executando um managed domain, o arquivo é o EAP_HOME/domain/configuration/domain.xml.
      2. Encontre o subsistema ee e adicione o módulo global para myorg-conf. Segue abaixo uma amostra do elemento do subsistema ee modificado para inclusão do elemento myorg-conf:
        <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
            <global-modules>
                <module name="myorg-conf" slot="main" />            
            </global-modules>
        </subsystem>
        
        
        Copy to Clipboard Toggle word wrap
  3. Assumindo que você copiou um arquivo nomeado my.properties à localização de módulo correta, você poderá agora carregar os arquivos de propriedades usando o código similar ao seguinte:
    Thread.currentThread().getContextClassLoader().getResource("my.properties");
    
    Copy to Clipboard Toggle word wrap

3.1.4. Alterações do Registro em Log

3.1.4.1. Modificação das Dependências de Registro em Log

Sumário

O JBoss LogManager suporta front ends para todos os frameworks de registro em log, de forma que você pode manter seu código de registro de log atual ou mover à nova infraestrutura de registro de log do JBoss. Independente de sua decisão, devido às alterações de carregamento de classe modular, você precisará provavelmente modificar seu aplicativo para adicionar as dependências requeridas.

Sumário

No JBoss EAP 6, as dependências de registro em log para frameworks de terceiros comuns como o Apache Commons Logging, Apache log4j, SLF4J e Java Logging são adicionados por default. No entanto, caso você esteja usando o log4j e você não deseja usar o subsistema de registro em log para configurar seus manuseadores (anexadores), você precisa excluir o módulo do log4j do JBoss EAP 6.

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

  1. Criação de um jboss-deployment-structure.xml com o seguinte conteúdo:
    <jboss-deployment-structure>
        <deployment>
            <!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
            <exclusions>
                <module name="org.apache.log4j" />
            </exclusions>
        </deployment>
    </jboss-deployment-structure>
    
    
    Copy to Clipboard Toggle word wrap
  2. Posicione o arquivo jboss-deployment-structure.xml tanto no diretório META-INF/ ou diretório WEB-INF/, caso esteja implantando um WAR ou no diretório META-INF/, caso você esteja implantando um EAR.
  3. Adicione o arquivo log4j.properties ou log4j.xml no diretório lib/ de seu EAR ou no diretório WEB-INF/classes/ de sua implantação WAR.
  4. Implante seu aplicativo.

Nota

Caso você deseje usar o arquivo de configuração log4j, você não estará mais apto à alterar a configuração do registro de log log4j no período de execução.
Sumário

Para usar o novo framework, altere suas importações e código conforme abaixo:

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

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

    Segue abaixo uma amostra do código que usa o novo framework do JBoss Logging:
    import org.jboss.logging.Level;
    import org.jboss.logging.Logger;
    
    private static final Logger logger = Logger.getLogger(MyClass.class.toString());
    
    if(logger.isTraceEnabled()) {
        logger.tracef("Starting...", subsystem);
    }
    
    Copy to Clipboard Toggle word wrap
  2. Adição de dependência de registro em log

    O JAR contendo as classes do JBoss Logging está localizado no módulo nomeado org.jboss.logging. O seu arquivo MANIFEST-MF deve parecer com o seguinte:
    Manifest-Version: 1.0
    Dependencies: org.jboss.logging
    
    Copy to Clipboard Toggle word wrap

3.1.5. Alterações do Empacotamento do Aplicativo

3.1.5.1. Modificação do Empacotamento dos EARS e WARs

Sumário

Quando você migrar seu aplicativo, é possível que você tenha que alterar a estrutura de empacotamento de seu EAR ou WAR devido à alteração do carregamento da classe modular. As dependências de módulo contém o carregamento em ordem específica:

  1. Dependências do sistema
  2. Dependências do Usuário
  3. Recursos Locais
  4. Dependências inter-implantadas

Procedimento 3.7. Modificação do empacotamento do arquivo

  1. Empacotamento do WAR

    O WAR é um módulo único e todas as classes no WAR são carregadas com o mesmo carregador de classe. Isto significa que as classes empacotadas no diretório WEB-INF/lib/ são tratadas da mesma forma que as classes no diretório WEB-INF/classes.
  2. Empacotamento de um EAR

    Um EAR consiste de módulos múltiplos. O diretório EAR/lib/ é um módulo único e cada WAR ou sub-implantação EJB jar no EAR é um módulo separado. As classes não possuem acesso às classes em outros módulos com o EAR, a não ser que as dependências tenham sido definidas. As sub-implantações sempre possuem uma dependência automática no módulo pai que as fornecem acesso às classes no diretório EAR/lib/. No entanto, as sub-implantações nem sempre possuem uma dependência automática para permitir que se acessassem entre si. Este comportamento é controlado pela configuração do elemento <ear-subdeployments-isolated> na configuração do subsistema ee, conforme abaixo:
    <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
      <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
    </subsystem>
    
    Copy to Clipboard Toggle word wrap
    Por default, isto é configurado para falso, permitindo que as sub-implantações vejam as classes pertencentes às demais sub-implantações com o EAR.
    Para maiores informações sobre o carregamento da classe, refira-se ao capítulo Carregamento de Classe e Módulos no Guia de Desenvolvimento para o JBoss EAP 6 no https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

3.1.6. Alterações da Configuração do Adaptador de Recurso e Fonte de Dados

3.1.6.1. Atualização do Aplicativo devido às Alterações da Configuração

No JBoss EAP 5, os serviços e subsistemas foram configurados em diversos arquivos diferentes. No JBoss EAP 6, a configuração é agora realizada basicamente em um arquivo. Caso o seu aplicativo usar qualquer um dos recursos ou serviços, as alterações da configuração podem ser necessárias.
  1. Caso o seu aplicativo usar uma fonte de dados, consulte a Seção 3.1.6.2, “Atualização da Configuração da Fonte de Dados”.
  2. Caso o seu aplicativo usar JPA e empacotar o Hibernate JARs, consulte as opções de migração na Seção 3.1.6.4, “Configuração da Fonte de Dados para o Hibernate ou JPA”.
  3. Caso o seu aplicativo usar um adaptador de recurso, consulte a Seção 3.1.6.5, “Atualização da Configuração do Adaptador de Recurso”.
  4. Revise abaixo as informações de como configurar as alterações para segurança básica na Seção 3.1.7.1, “Configuração das Alterações de Segurança do Aplicativo”.

3.1.6.2. Atualização da Configuração da Fonte de Dados

Sumário

Nas versões anteriores do JBoss EAP, a configuração da fonte de dados JCA foi definida num arquivo com sufixo *-ds.xml. Esse arquivo foi implantado no diretório deploy/ do servidor ou empacotado com o aplicativo. O driver JDBC foi copiado ao diretório server/lib/ ou empacotado no diretório WEB-INF/lib/ do aplicativo. Enquanto esse método de configuração de fonte de dados não é suportado para o desenvolvimento, ele não é recomendado para produção uma vez que ele não é suportado pelas ferramentas de gerenciamento e administrativa do JBoss.

No JBoss EAP 6, a fonte de dados é configurada no arquivo de configuração do servidor. Caso a instância do JBoss EAP estiver sendo executada num managed domain, a fonte de dados é configurada no arquivo domain/configuration/domain.xml. Caso a instância do JBoss EAP estiver sendo executada como servidor autônomo, a fonte de dados é configurada no standalone/configuration/standalone.xml file. As fontes de dados configuradas dessa maneira podem ser gerenciadas e controladas usando as interfaces de gerenciamento do JBoss, incluindo o Web Management Console (Management Console da Web) e a interface da linha de comando (CLI). Essas ferramentas facilitam o gerenciamento de implantações e configuram servidores múltiplos sendo executados no managed domain.
A seguinte seção descreve como modificar sua configuração de fonte de dados, de forma que ela pode ser gerenciada e suportada pelas ferramentas de gerenciamento disponíveis.
Migração para uma Configuração de Fonte de Dados Gerenciável para o JBoss EAP 6

Um driver compatível com JDBC 4.0 pode ser instalado como implantação ou como módulo core. Um driver que é compatível com o JDBC 4.0 contém um arquivo META-INF/services/java.sql.Driver que especifica o nome da classe do driver. Um driver que não é compatível com o JDBC 4.0 requer etapas adicionais. Para maiores detalhes de como fazer um driver compatível com o JDBC 4.0 e como atualizar sua configuração de fonte de dados atual para uma que é gerenciável pelo Management Console da Web e CLI, consulte a Seção 3.1.6.3, “Instalação e Configuração do JDBC Driver”.

Caso seu aplicativo usar Hibernate ou JPA, ele poderá requerer alterações adicionais. Consulte a Seção 3.1.6.4, “Configuração da Fonte de Dados para o Hibernate ou JPA” para maiores informações.
Use a Ferramenta de Migração IronJacamar para Converter os Dados de Configuração

Você pode usar a ferramenta IronJacamar para migrar a fonte de dados e as configurações do adaptador do recurso. Esta ferramenta converte os arquivos de configuração do estilo *-ds.xml no formato esperado pelo JBoss EAP 6. Consute: Seção 4.1.6, “Uso da Ferramenta IronJacamar para Migração da Fonte de Dados e Configurações do Adaptador de Recurso” para maiores informações.

3.1.6.3. Instalação e Configuração do JDBC Driver

Sumário

O JDBC driver pode ser instalado no contêiner em uma das duas seguintes maneiras:

  • como implantação
  • como módulo core
Os aspectos positivos e negativos de cada abordagem estão descritos abaixo.

No JBoss EAP 6, a fonte de dados é configurada no arquivo de configuração do servidor. Caso a instância do JBoss EAP 6 estiver sendo executada num managed domain, a fonte de dados é configurada no arquivo domain/configuration/domain.xml. Caso a instância do JBoss EAP 6 estiver sendo executada como um servidor autônomo, a fonte de dados é configurada no arquivo standalone/configuration/standalone.xml. A informação da referência do esquema, que é a mesma em ambos os modos, pode ser encontrada no diretório doc/ de instalação do JBoss EAP 6. Para propósitos desta discussão, assuma que o servidor está sendo executado como servidor autônomo e a fonte de dados está configurada no arquivo standalone.xml.

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

  1. Instalação do JBBC Driver

    1. Instale o JDBC Driver como uma implantação

      Esta é a maneira recomendada para instalar o driver. Quando o JDBC driver for instalado como uma implantação, ele é implantado como um JAR regular. Caso a instância do JBoss EAP 6 estiver sendo executada como um servidor autônomo, copie o JDBC 4.0 compatível ao JAR no diretório EAP_HOME/standalone/deployments/. Caso o servidor estiver sendo executado num managed domain, copie o JAR ao diretório EAP_HOME/domain/deployments/.
      Segue abaixo uma amostra de um MySQL JDBC driver instalado como implantação ao servidor autônomo:
      $cp mysql-connector-java-5.1.15.jar EAP_HOME/standalone/deployments/
      Copy to Clipboard Toggle word wrap
      Qualquer driver compatível com o JDBC 4.0 é automaticamente reconhecido e instalado no sistema pelo nome e versão. Um JAR compatível com o JDBC 4.0 contém um texto com arquivo nomeado META-INF/services/java.sql.Driver que especifica o(s) nome(s) da classe do driver. Caso o driver não for compatível com o JDBC 4.0, ele pode ser implantável em uma das seguintes maneiras:
      • Crie e adicione o arquivo java.sql.Driver ao JAR sob o caminho META-INF/services/. Esse arquivo deve conter o nome de classe do driver, por exemplo:
        com.mysql.jdbc.Driver
        Copy to Clipboard Toggle word wrap
      • Crie um arquivo java.sql.Driver no diretório de implantação. Para uma instância do JBoss EAP 6 sendo executada como servidor autônomo, o arquivo deve ser posicionado aqui: EAP_HOME/standalone/deployments/META-INF/services/java.sql.Driver. Caso o servidor estiver num managed domain, o arquivo deve ser posicionado aqui: EAP_HOME/domain/deployments/META-INF/services/java.sql.Driver.
      Os aspectos positivos desta abordagem são:
      • Este é o método mais simples uma vez que não há necessidade de definir um módulo.
      • Quando o servidor estiver executando num managed domain, as implantações que usam esta abordagem são propagadas automaticamente a todos os servidores no domain. Isto significa que o administrador não precisa distribuir o driver JAR manualmente.
      Os aspectos negativos desta abordagem são:
      • Caso o JDBC driver consistir de mais de um JAR, por exemplo: o driver JAR mais um JAR com licença independente ou JAR de localização, você não pode instalar o driver como uma implantação. Você deve instalar o JDBC driver como um módulo core.
      • Caso o driver não for compatível com o JDBC 4.0, um arquivo deve ser criado contendo o(s) nome(s) da classe do driver e deve ser importado num JAR ou sobreposto no diretório deployments/.
    2. Instale o JDBC Driver como módulo core

      Para instalar um JDBC driver como um módulo core, você deve criar uma estrutura do caminho do arquivo sob o diretório EAP_HOME/modules/. Esta estrutura contém o JDBC driver JAR, qualquer licença do fornecedor adicional ou JARs de localização e um arquivo module.xml para definir o módulo.
      • Instale o MySQL JDBC Driver como módulo core

        1. Crie uma estrutura de diretório EAP_HOME/modules/com/mysql/main/
        2. No subdiretório main/, crie um arquivo module.xml contendo a seguinte definição do módulo para o MySQL JDBC driver:
          <?xml version="1.0" encoding="UTF-8"?>
          <module xmlns="urn:jboss:module:1.0" name="com.mysql">
          <resources>
              <resource-root path="mysql-connector-java-5.1.15.jar"/>
          </resources>
          <dependencies>
              <module name="javax.api"/>
          </dependencies>
          </module>
          
          
          
          Copy to Clipboard Toggle word wrap
          O nome do módulo, "com.mysql", coincide com a estrutura do diretório para esse módulo. O elemento <dependencies> é usado para especificar as dependências do módulo em outros módulos. Neste caso, como é o caso em todas as fontes de dados JDBC, isto é dependente do Java JDBC APIs que é definido em outro módulo nomeado javax.api. Este módulo está localizado sob o diretório modules/system/layers/base/javax/api/main/.

          Nota

          Certifique-se de que você NÃO possui espaço no início do arquivo module.xml ou você obterá um erro "New missing/unsatisfied dependencies" para este driver.
        3. Copie o MySQL JDBC driver JAR ao diretório EAP_HOME/modules/com/mysql/main/:
          $ cp mysql-connector-java-5.1.15.jar EAP_HOME/modules/com/mysql/main/
          Copy to Clipboard Toggle word wrap
      • Instale o IBM DB2 JDBC driver e licença JAR como um módulo core

        Esta amostra é fornecida para apenas demonstrar como implantar drivers que requerem JARs além do JDBC Driver JAR.
        1. Crie a estrutura do diretório EAP_HOME/modules/com/ibm/db2/main/.
        2. No subdiretório main/ crie um arquivo module.xml contendo a seguinte definição do módulo para o IBM DB2 JDBC driver e licença:
          <?xml version="1.0" encoding="UTF-8"?>
          <module xmlns="urn:jboss:module:1.1" name="com.ibm.db2">
            <resources>
              <resource-root path="db2jcc.jar"/>
              <resource-root path="db2jcc_license_cisuz.jar"/>
            </resources>
            <dependencies>
              <module name="javax.api"/>
              <module name="javax.transaction.api"/>
            </dependencies>
          </module>
          
          
          Copy to Clipboard Toggle word wrap

          Nota

          Certifique-se de que você NÃO possui espaço no início do arquivo module.xml ou você obterá um erro "New missing/unsatisfied dependencies" para este driver.
        3. Copie o JDBC driver e a licença JAR ao diretório EAP_HOME/modules/com/ibm/db2/main/.
          $ cp db2jcc.jar EAP_HOME/modules/com/ibm/db2/main/
          $ cp db2jcc_license_cisuz.jar EAP_HOME/modules/com/ibm/db2/main/
          Copy to Clipboard Toggle word wrap
      Os aspectos positivos desta abordagem são:
      • Esta é a única abordagem que funciona quando o JDBC driver consiste de mais de um JAR.
      • Com esta abordagem, os drivers que não são compatíveis com o JDBC 4.0 podem ser instalados sem modificar o driver JAR ou criando uma sobreposição de arquivo.
      Os aspectos negativos desta abordagem são:
      • É mais difícil configurar um módulo.
      • O módulo deve ser manualmente copiado para cada servidor executando num managed domain.
  2. Configuração da fonte de dados

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

      Adicione o elemento <driver> ao elemento <drivers> de mesmo arquivo. Isto contém algumas das informações que foram definidas anteriormente no arquivo *-ds.xml.
      Primeiro determine se o driver JAR é compatível com o JDBC 4.0. Um JAR que é compatível com o JDBC 4.0 contém um arquivo META-INF/services/java.sql.Driver que especifica o nome de classe do driver. O servidor usa este arquivo para encontrar o nome da(s) classe(s) de driver no JAR. Um driver que é compatível com o JDBC 4.0 não requer um elemento <driver-class>, uma vez que ele já está especificado no JAR. Esta é uma amostra do elemento do driver para um JDBC 4.0 compatível com o driver MySQL:
      <driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"/>
      
      Copy to Clipboard Toggle word wrap
      Um driver que não seja compatível com o JDBC 4.0 requer um atributo <driver-class> para identificar a classe do driver desde que não haja um arquivo META-INF/services/java.sql.Driver que especifique o nome da classe do driver. Segue abaixo uma amostra do elemento driver para o driver não compatível com o JDBC 4.0:
      <driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"><driver-class>com.mysql.jdbc.Driver</driver-class></driver>
      
      
      Copy to Clipboard Toggle word wrap
    2. Criação da fonte de dados

      Crie um elemento <datasource> na seção <datasources> do arquivo standalone.xml. Este arquivo contém bastante informações da fonte de dados anteriormente definida no arquivo *-ds.xml.

      Importante

      Você deve interromper o servidor antes de editar o arquivo de configuração do servidor para que sua alteração seja persistida na iniciação do servidor.
      Segue abaixo uma amostra de um elemento de fonte de dados MySQL no arquivo standalone.xml:
      <datasource jndi-name="java:/YourDatasourceName" pool-name="YourDatasourceName">
        <connection-url>jdbc:mysql://localhost:3306/YourApplicationURL</connection-url>
        <driver>mysql-connector-java-5.1.15.jar</driver>
        <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
        <pool>
          <min-pool-size>100</min-pool-size>
          <max-pool-size>200</max-pool-size>
        </pool>
        <security>
          <user-name>USERID</user-name>
          <password>PASSWORD</password>
        </security>
        <statement>
          <prepared-statement-cache-size>100</prepared-statement-cache-size>
          <share-prepared-statements/>
        </statement>
      </datasource>
      
      
      Copy to Clipboard Toggle word wrap

3.1.6.4. Configuração da Fonte de Dados para o Hibernate ou JPA

Caso o seu aplicativo usar o JPA e empacotar atualmente JBoss JARs, você deverá usar o Hibernate que está incluso com o JBoss EAP 6. Para uso dessa versão do Hibernate, você deve remover o pacote antigo do Hibernate de seu aplicativo.

Procedimento 3.9. Remoção do pacote Hibernate

  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.

3.1.6.5. Atualização da Configuração do Adaptador de Recurso

Sumário

Nas versões anteriores do servidor do aplicativo, a configuração do adaptador do recurso era definido num arquivo com um sufixo *-ds.xml. No JBoss EAP 6, o adaptador de recurso é configurado no arquivo de configuração do servidor. Caso você esteja executando num managed domain, o arquivo de configuração é o arquivo EAP_HOME/domain/configuration/domain.xml. Caso você esteja executando como um servidor autônomo, configure o adaptador de recurso no arquivo EAP_HOME/standalone/configuration/standalone.xml. A informação da referência do esquema, que é a mesma para ambos os módulos, pode ser encontrada no Resource adapter descriptors.

Importante

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.
Definição do adaptador de recurso

A informação do descritor do adaptador de recurso está definida no elemento do seguinte subsistema no arquivo de configuração do servidor:

<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1"/>
Copy to Clipboard Toggle word wrap
Você usará algumas das informações definidas anteriormente no arquivo *-ds.xml do adaptador de recurso.

Segue abaixo uma amostra do elemento do adaptador de recurso no arquivo de configuração do servidor:
<resource-adapters>
  <resource-adapter>
    <archive>multiple-full.rar</archive>
    <config-property name="Name">ResourceAdapterValue</config-property>
    <transaction-support>NoTransaction</transaction-support>
    <connection-definitions>
      <connection-definition
      class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleManagedConnectionFactory1"
      enabled="true" jndi-name="java:/eis/MultipleConnectionFactory1"
      pool-name="MultipleConnectionFactory1">
    <config-property name="Name">MultipleConnectionFactory1Value</config-property>
      </connection-definition>
      <connection-definition
      class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleManagedConnectionFactory2"
      enabled="true" jndi-name="java:/eis/MultipleConnectionFactory2"
      pool-name="MultipleConnectionFactory2">
    <config-property name="Name">MultipleConnectionFactory2Value</config-property>
      </connection-definition>
    </connection-definitions>
    <admin-objects>
      <admin-object
      class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleAdminObject1Impl"
      jndi-name="java:/eis/MultipleAdminObject1">
    <config-property name="Name">MultipleAdminObject1Value</config-property>
      </admin-object>
      <admin-object class-name="org.jboss.jca.test.deployers.spec.rars.multiple.MultipleAdminObject2Impl"
      jndi-name="java:/eis/MultipleAdminObject2">
    <config-property name="Name">MultipleAdminObject2Value</config-property>
      </admin-object>
      </admin-objects>
  </resource-adapter>
</resource-adapters>
Copy to Clipboard Toggle word wrap

3.1.7. Alterações de Segurança

3.1.7.1. Configuração das Alterações de Segurança do Aplicativo

Configure a segurança para a autenticação básica

Nas versões anteriores do JBoss EAP, os arquivos de propriedades posicionados no diretório EAP_HOME/server/SERVER_NAME/conf/ estavam no classpath e poderiam ser facilmente encontrados pelo UsersRolesLoginModule. No JBoss EAP 6, a estrutura do diretório foi alterada. Os arquivos da propriedade devem ser empacotados com aplicativo para disponibilizá-los no classpath.

Importante

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.
Para configurar a segurança para uma autenticação básica, adicione um novo security domain sob o security-domains para o standalone/configuration/standalone.xml ou o arquivo de configuração do servidor domain/configuration/domain.xml:
<security-domain name="example">
    <authentication>
        <login-module code="UsersRoles" flag="required">
            <module-option name="usersProperties" 
                    value="${jboss.server.config.dir}/example-users.properties"/>
            <module-option name="rolesProperties" 
                    value="${jboss.server.config.dir}/example-roles.properties"/>
        </login-module>
    </authentication>
</security-domain>
Copy to Clipboard Toggle word wrap
Caso a instância do JBoss EAP 6 estiver sendo executada como um servidor autônomo, o ${jboss.server.config.dir} refere-se ao diretório EAP_HOME/standalone/configuration/. Caso a instância estiver executando num managed domain, o ${jboss.server.config.dir} refere-se ao diretório EAP_HOME/domain/configuration/.
Modificação dos nomes do security domain

Os security domains não usam mais o prefixo java:/jaas/ em seus nomes no JBoss EAP 6.

  • Você deve remover esse prefixo das configurações do security domain para os aplicativos da Web no jboss-web.xml.
  • Você deve remover esse prefixo das configurações do security domain para os aplicativos Enterprise no jboss-web.xml. Esse arquivo foi substituído pelo jboss.xml no JBoss EAP 6.

3.1.8. Alterações JNDI

3.1.8.1. Atualização dos Nomes JNDI Namespace do Aplicativo

Sumário

O EJB 3.1 introduzido a um JNDI namespace glogal padronizado e uma série de namespaces relacionados que mapeiam várious escopos do aplicativo Java EE. Os nomes do EJB Portátil é apenas limitado a três deles: java:global, java:module e java:app. Os aplicativos com os EJBs que usam o JNDI devem ser alterados para seguirem a nova convenção padronizada do JNDI namespace.

Amostra de Mapeamentos JNDI

As amostras de espaços de nome JNDI dos lançamentos anteriores e como eles são especificados no JBoss EAP podem ser encontradas na: Seção 3.1.8.5, “Amostra do JNDI Namespaces nos Lançamentos Anteriores e como são especificados no JBoss EAP 6”

3.1.8.2. Nomes do EJB JNDI Portátil

Sumário

A especificação do Java EE 6 define quatro namespaces lógicos, cada um com o seu próprio escopo. No entanto, os nomes do EJB portátil apenas obtém o limite de três deles. A seguinte tabela detalha quando e como usar cada namespace.

Expand
Tabela 3.1. Namespaces JNDI Portáveis
JNDI Namespace Descrição
java:global
Os nomes neste namespace são compartilhados em todos os aplicativos implantados numa instância do servidor do aplicativo. Use nomes neste namespace para encontrar os arquivos EJBs externos ao mesmo servidor.
Segue abaixo uma amostra do java:global namespace: java:global/jboss-seam-booking/jboss-seam-booking-jar/HotelBookingAction
java:module
Os nomes neste namespace são compartilhados por todos os componentes num módulo, por exemplo: todos os enterprise beans num módulo EJB único ou todos os componentes num módulo da web.
Segue abaixo uma amostra do java:module namespace: java:module/HotelBookingAction!org.jboss.seam.example.booking.HotelBooking
java:app
Os nomes neste namespace são compartilhados por todos os componentes num aplicativo único. Por exemplo, um WAR e um arquivo EJB jar no mesmo arquivo EAR teria acesso recursos no java:app namespace.
Segue abaixo uma amostra do java:app namespace: java:app/jboss-seam-booking-jar/HotelBookingAction
Você pode encontrar maiores informações sobre os contextos de nomeação JNDI na seção EE.5.2.2, "Application Component Environment Namespaces" no "JSR 316: JavaTM Platform, Enterprise Edition (Java EE) Specification, v6". Você pode baixar a especificação a partir do http://jcp.org/en/jsr/detail?id=316

3.1.8.3. Revisão das Regras JNDI Namespace

Sumário

O JBoss EAP 6 aprimorou os nomes do JNDI namespace, não apenas para fornecer regras consistentes e premeditadas para cada nome limitado no servidor do aplicativo, mas também para prevenir problemas futuros de compatibilidade. Isto significa que você poderá ter problemas com os namespaces atuais no seu aplicativo, caso eles não seguirem as novas regras.

Os namespaces devem seguir as seguintes regras:

  1. Os nomes relativos não qualificados como o DefaultDS ou jdbc/DefaultDS devem ser relativamente qualificados para o java:comp/env, java:module/env ou java:jboss/env, dependendo do contexto.
  2. Os nomes absolute não qualificados como /jdbc/DefaultDS devem ser relativamente qualificados a um nome java:jboss/root.
  3. Os nomes absolute qualificados como o java:/jdbc/DefaultDS devem ser qualificados da mesma forma que os nomes absolute não qualificados acima.
  4. O espaço do nome java:jboss especial é compartilhado por toda a instância do servidor AS.
  5. Qualquer nome relative com o prefixo java: deve estar em um dos cinco espaços do nome: comp, module, app, global ou jboss proprietário. Qualquer nome começando com java:xxx onde xxx não combina com nenhum dos cinco acima e resultaria num erro de nome inválido.

  • Segue abaixo uma amostra da pesquisa JNDI no JBoss EAP 5.1. Este código é normalmente encontrado num método de inicialização.
    private ProductManager productManager;
    try {
        context = new InitialContext();
        productManager = (ProductManager) context.lookup("OrderManagerApp/ProductManagerBean/local");
    } catch(Exception lookupError) {
        throw new ServletException("Unable to find the ProductManager bean", lookupError);
    }
    
    Copy to Clipboard Toggle word wrap
    Note que o nome de pesquisa é OrderManagerApp/ProductManagerBean/local.
  • Segue abaixo uma amostra de como a mesma pesquisa seria codificada no JBoss EAP 6 usando o CDI.
    @EJB(lookup="java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager")
    private ProductManager productManager;
    
    Copy to Clipboard Toggle word wrap
    Os valores de pesquisa são definidos como variáveis do associado e usam o novo nome java:app JNDI namespace java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager.
  • Caso você prefira não usar o CDI, você pode continuar a criar um novo InitialContext conforme acima e modificar a pesquisa para uso do novo nome JNDI namespace.
    private ProductManager productManager;
    try {
        context = new InitialContext();
        productManager = (ProductManager) context.lookup("java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager");
    } catch(Exception lookupError) {
        throw new ServletException("Unable to find the ProductManager bean", lookupError);
    }
    
    Copy to Clipboard Toggle word wrap

Expand
Tabela 3.2.
Namespace no JBoss EAP 5.x Namespace no JBoss EAP 6 Comentários adicionais
OrderManagerApp/ProductManagerBean/local java:module/ProductManagerBean!services.ejb.ProductManager O Java EE 6 binding default. Possui escopo para o módulo atual e apenas acessível com o mesmo módulo.
OrderManagerApp/ProductManagerBean/local java:app/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager O Java EE 6 binding default. Possui escopo para o aplicativo atual e apenas acessível com o mesmo aplicativo.
OrderManagerApp/ProductManagerBean/local java:global/OrderManagerApp/OrderManagerEJB/ProductManagerBean!services.ejb.ProductManager O binding default do Java EE 6. Possui escopo para o servidor do aplicativo e acessível globalmente.
java:comp/UserTransaction java:comp/UserTransaction O namespace possui escopo ao componente atual. Não é acessível para threads que não estão no Java EE 6, por exemplo: os threads criados diretamente pelo seu aplicativo.
java:comp/UserTransaction java:jboss/UserTransaction Acessível globalmente. Use isto caso o java:comp/UserTransaction não esteja disponível.
java:/TransactionManager java:jboss/TransactionManager
java:/TransactionSynchronizationRegistry java:jboss/TransactionSynchronizationRegistry
Voltar ao topo
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2026 Red Hat