3.2.11. Alterações em EJB 2.x

3.2.11.1. Atualização dos Aplicativos que usam EJB 2.x

O JBoss EAP 6 foi construído nos padrões abertos e é compatível com a especificação do Java Enterprise Edition 6. Embora o servidor do aplicativo forneça suporte para o EJB 2.x, ele não suporta mais os recursos que vão além da especificação. Lembre-se de que a especificação Java EE 7 marcou o EJB 2.x como uma opção, portanto é altamente recomendável que você regrave o código do seu aplicativo na especificação EJB 3.x.

Caso ainda queira migrar o seu código EJB 2.x, será necessário, na maioria das vezes, fazer modificações para executar no JBoss EAP 6. O tópico a seguir descreve algumas alterações que possam ser necessárias para executar o EJB 2.x no JBoss EAP 6.

Alterações de Configuração Necessárias para Executar o EJB 2.x no JBoss EAP 6

Inicie o Servidor com o Perfil Completo

Os beans de Persistência Gerenciada pelo Contêiner (do inglês, Container Managed Persistence - CMP) EJB 2.x requerem o perfil completo da Edição 6 do Java Enterprise. Este perfil contém elementos de configuração que são necessários para executar CMP EJBs.

Este perfil de configuração contém o módulo de extensão org.jboss.as.cmp:

<extensions>
    ...
    <extension module="org.jboss.as.cmp"/>
    ...
</extensions>

Ele contém também o subsistema cmp:

<profiles>
    ...
    <subsystem xmlns="urn:jboss:domain:cmp:1.1"/>
    ...
</profiles>

Para iniciar um servidor autônomo do JBoss EAP 6 com o perfil completo, passe o argumento -c standalone-full.xml ou -c standalone-full-ha.xml na linha de comando quando iniciar o servidor.

A Configuração do Contêiner Não É Mais Suportada

Nas versões anteriores do JBoss EAP, era possível configurar um contêiner diferente para a entidade CMP e outros beans e usá-lo estabelencdo referências dentro do arquivo do descritor de implantação do aplicativo jboss.xml. Por exemplo, haviam configurações diferentes, no geral, para SLSB para beans de sessão.

No JBoss EAP 6.x, é possível usar os beans de Entidade EJB 2 com um contêiner padrão. No entanto, as configurações de contêiner diferentes não possuem mais suporte. A abordagem recomendada é migrar os Beans de Sessão com Monitorização de Estado (do inglês, Stateful Session Beans - SFSB ), os Beans de Sessão sem Monitorização de Estado (do inglês, Stateless Session Beans - SLSB), os Beans Controlados por Mensagem (do inglês, Message Driven Beans - MDB ) EJB2 para EJB 3, e quanto à Persistência Gerenciada Pelo Contêiner (CMP) e aos Beans de Entidade de Persistência Gerenciada pelo Bean (do inglês, Bean-Managed Persistence - BMP) usar a API de Persistência Java (do inglês, Java Persistence API - JPA ) de acordo com a especificação EJB 3.

A configuração do contêiner padrão no JBoss EAP 6 contém algumas alterações para os beans CMP EJB 2:

O bloqueio pessimista é ativo por padrão. Isto pode resultar em travamentos.
O código de detecção de travamento que estava na camada CMP no JBoss EAP 5.x não faz mais parte do JBoss EAP 6.

No JBoss EAP 5.x, era possível personalizar o cache, o pool, commit-options e a pilha do interceptor. No JBoss EAP 6, isto não é mais possível. Existe apenas uma implementação, que é parecida com a política Instância por transação com commit-option C. Caso você migre um aplicativo que utiliza a configuração do contêiner do bean de entidade cmp2.x jdbc2 pm, que usa um gerenciador de persistência baseado em JDBC compatível com CMP2.x, haverá um impacto no desempenho. Este contêiner foi otimizado para melhor desempenho. Recomenda-se a migração destas entidades ao EJB 3 antes de migrar o aplicativo.

Configuração do Interceptor ao Lado do Servidor

O JBoss EAP 6 suporta o Java EE Interceptor padrão usando as anotações @Interceptors e @AroundInvoke. No entanto, isto não permite a manipulação fora da Segurança ou Transação.

Nas versões anteriores do JBoss EAP, era possível modificar a pilha do interceptor para possuir interceptores personalizados para cada invocação EJB. Isto era normalmente usado para implementar uma segurança personalizada ou repetir mecanismos, antes das verficações de segurança ou verificações de transação ou criação. O JBoss EAP 6.1 introduziu os interceptores de contêiner para fornecer uma funcionalidade semelhante. Para mais informações sobre os interceptores de contêiner, consulte o capítulo entitulado Container Interceptor no guia Development Guide do JBoss EAP.

Uma outra abordagem para fornecer mais controle antes, durante ou após a fase de confirmação de uma transação, enquanto mantendo a especificação Java EE, é usar o Registro de Sincronização de Transação para a adição de um ouvinte.

O recurso pode ser recuperado usando um dos seguintes métodos:

Use InitialContext

TransactionSynchronizationRegistry tsr = (TransactionSynchronizationRegistry) 
		new InitialContext().lookup("java:jboss/TransactionSynchronizationRegistry");
tsr.registerInterposedSynchronization(new MyTxCallback());

Use Injeção

@Resource(mappedName = "java:comp/TransactionSynchronizationRegistry")
TransactionSynchronizationRegistry tsr;
...
tsr.registerInterposedSynchronization(new MyTxCallback());

A routina de retorno de chamada deve implementar a Interface javax.transaction.Synchronization. Use o método beforeCompletion{} para desempenhar quaisquer verificações antes que a transação seja confirmada ou revertida. Se um RuntimeException for lançado a partir deste método, a transação é revertida e o cliente é notificado com um EJBTransactionRolledbackException. No caso de um XA-Transaction, todos os recursos serão revertidos de acordo com o contrato XA. É possível também habilitar a lógica comercial para depender do estado da transação usando o método afterCompletion(int txStatus). Caso um RuntimeException seja lançado a partir deste método, a transação permanece no estado anterior, confirmada ou revertida, e o cliente não é notificado. Apenas o gerenciador da transação apresenta um aviso dentro dos arquivos de log do servidor.

Configuração ao Lado do Servidor para Interceptores ao Lado do Cliente

Nas versões anteriores do JBoss EAP, era possível configurar os interceptores do cliente com a configuração do servidor e fornecer apenas as classes com a API do cliente.

No JBoss EAP 6, isto não é mais possível já que o Proxy do cliente não é mais criado ao lado do servidor e transmitido ao cliente após a pesquisa. O proxy é agora gerado ao lado do cliente. Esta otimização evita uma invocação do servidor para os carregamentos de classe e pesquisa.

Configuração do Pool de Beans de Entidades

A configuração do pool de beans de entidades não é recomendada no JBoss EAP 6. Isto deve-se a ela ser limitada à configuração do elemento <strict-max-pool>, travamentos e outros problemas que podem ocorrer caso o pool seja muito pequeno para carregar todas as entidades no conjunto de resultado. Os beans de entidade não possuem amplos métodos de ciclo de vida durante a inicialização, portanto criar a instância e cercar o contêiner não é mais lento do que quando se utiliza uma instância de bean de entidade em pool.

Substituição do Arquivo do Descritor de Implantação jboss.xml

O descritor de implementação jboss-ejb3.xml substitui o arquivo do descritor de implantação jboss.xml. Este arquivo é usado para substituir e adicionar os recursos fornecidos pelo Java Enterprise Edition (EE), definidos no descritor de implantação ejb-jar.xml. O novo arquivo, incompatível com jboss.xml e jboss.xml, é agora ignorado nas implantações.

Por exemplo, nas versões anteriores do JBoss EAP, caso fosse definido um <resource-ref> no arquivo ejb-jar.xml, você necessitaria de uma definição de recurso correspondente para o nome JNDI no arquivo jboss.xml. XDoclet gerava automaticamente ambos os arquivos do descritor de implantação. No JBoss EAP 6, a informação de mapeamento JNDI é agora definida no arquivo jboss-ejb3.xml. Suponhe que a fonte de dados esteja definida no código de fonte Java, como segue.

DataSource ds1 = (DataSource) new InitialContext().lookup("java:comp/env/jdbc/Resource1");
DataSource ds2 = (DataSource) new InitialContext().lookup("java:comp/env/jdbc/Resource2");

ejb-jar.xml define as seguintes referências de recurso.

<resource-ref >
    <res-ref-name>jdbc/Resource1</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
</resource-ref>
<resource-ref >
    <res-ref-name>java:comp/env/jdbc/Resource2</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
</resource-ref>

O arquivo jboss-ejb3.jxml mapeia os nomes JNDI às referências usando a seguinte sintaxe XML.

<resource-ref>
    <res-ref-name>jdbc/Resource1</res-ref-name>
    <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
</resource-ref>
<resource-ref>
    <res-ref-name>java:comp/env/jdbc/Resource2</res-ref-name>
    <jndi-name>java:jboss/datasources/ExampleDS</jndi-name>
</resource-ref>

Algumas das opções de configuração que estavam disponíveis no JBoss EAP 5.x do arquvivo jboss.xml não foram implementadas no JBoss EAP 6. A lista a seguir descreve alguns dos atributos comumente usados no arquivo jboss.xml e se há uma maneira alternativa de arquivá-los no JBoss EAP 6.

O elemento method-attribute era usado para configurar entidades individuais e métodos de beans de sessão.
- As opções de configuração read-only e idempotent não foram transportadas para o JBoss EAP 6.
- A opção transaction-timeout está agora configurada no arquivo jboss-ejb3.xml.
O atributo missing-method-permission-exclude-mode alterou o comportamento dos métodos sem implementar metadados de segurança explícitos em um bean protegido. No JBoss EAP 6, a ausência de uma anotação @RolesAllowed é tratada atualmente de forma semelhante ao @PermitAll

Configuração de Mapeamento do Tipo de Fonte de Dados

Nas versões anteriores do JBoss EAP, era possível configurar o mapeamento do tipo de fonte de dados dentro do arquivo de configuração de implantação da fonte de dados *-ds.xml.

No JBoss EAP 6, isto deve ser realizado agora no arquivo do descritor de implantação jbosscmp-jdbc.xml.

<defaults>  
    <datasource-mapping>mySQL</datasource-mapping>  
    <create-table>true</create-table>  
    ....  
</defaults>

Nas versões anteriores do JBoss EAP, o mapeamento personalizado era feito no arquivo standardjbosscmp-jdbc.xml. Este arquivo não está mais disponível e o mapeamento é agora realizado no arquivo do descritor de implantação jbosscmp-jdbc.xml.

Alterações Adicionais da Persistência Gerenciada pelo Contêiner (CMP) e do Relacionamento Gerenciado pelo Contêiner (CMR)

Alterações de Coleção e do Interador do Relacionamento Gerenciado pelo Contêiner (CMR): Nas versões anteriores do JBoss EAP, era possível para alguns contêiners, como por exemplo, o contêiner cmp2.x jdbc2 pm, interar as coleções CMR, além de remover e adicionar relações. Isto não é mais possível no JBoss EAP 6, já que a configuração do contêiner não é suportada. Consulte EJB2.1 Finder for CMP entities with relations (CMR) returns duplicates in EAP6 na seção de Soluções da Base de Conhecimento de Suporte do Portal do Consumidor, para mais informações sobre como atingir esta mesma funcionalidade no código do aplicativo.
Entradas Duplicadas do Relacionamento Gerenciado pelo Contêiner (CMR) para Localizadores: Nas versões anteriores do JBoss EAP, era possível selecionar contêineres CMP diferentes que usavam estratégias de persistência diferentes. O contêiner cmp2.x jdbc2 pm no JBoss EAP 5.x usava SQL-92 otimizado para gerar a sintaxe LEFT OUTER JOIN otimizada para localizadores. A implementação não contém essas otimizações, já que o Boss EAP 6.x suporta apenas o contêiner padrão para CMP e CMR. O localizador deve incluir a palavra-chave DISTINCT na declaração SELECT para evitar um produto cartesiano no conjunto de resultado. Consulte EJB2.1 Finder for CMP entities with relations (CMR) returns duplicates in EAP6 na seção de Soluções da Base de Conhecimento de Suporte do Portal do Consumidor para mais informações.
Alteração Padrão de Exclusão em Cascata para os Beans de Entidade CMP: O valor padrão de exclusão em cascata foi alterado para false. Isto pode resultar em falhas de exclusão no JBoss EAP 6. Se as relações de entidades estiverem marcadas como cascade-delete, batch-cascade-delete deve ser explicitamente configurado como true no arquivo jbosscmp-jdbc.xml. Para mais informações, consulte cascade delete fail for EJB2 CMP Entities after migration to EAP6 na seção de Soluções da Base de Conhecimento de Suporte do Portal do Consumidor.
Mapeadores Personalizados de CMP para Campos Personalizados: Se você utilizou classes de mapeador do cliente, tais como JDBCParameterSetter, JDBCResultSetReader e Mapper em seu aplicaitivo JBoss EAP 5.x, você pode encontrar java.lang.ClassNotFoundException quando implantar seu aplicativo ao JBoss EAP 6. Isto é devido aos nomes de pacotes para as interfaces terem sido alterados de org.jboss.ejb.plugins.cmp.jdbc.Mapper para org.jboss.as.cmp.jdbc.Mapper. Para mais informações, consulte How to use Field mapping for custom classes in an EJB2 CMP application in EAP6 na seção de Soluções da Base de Conhecimento de Suporte do Portal do Consumidor.
Geração de Chaves Primárias Usando comandos de entidade: Caso o seu aplicativo JBoss EAP 5 use entity-commands para gerar chaves primárias, por exemplo Sequence ou Auto-increment, você pode encontrar um ClassNotFoundException para a classe JDBCOracleSequenceCreateCommand quando migrar o seu aplicativo para JBoss EAP 6. Isto é devido ao pacote de classe ter sido alterado de org.jboss.ejb.plugins.cmp.jdbc para org.jboss.as.cmp.jdbc.keygen. Caso utilize esta classe no seu aplicativo JBoss EAP 6, uma dependência deve ser adicionada no módulo EAP_HOME/modules/system/layers/base/org/jboss/as/cmp.

Alterações no Aplicativo

Modifique o Código para Usar as Novas Regras do Namespace JNDI.

Assim como EJB 3.0, você deve usar o prefixo JNDI completo com EJB 2.x. Consulte Seção 3.1.8.1, “Atualização dos Nomes do Namespace JNDI do Aplicativo” para mais informações sobre as novas regras do namespace JNDI e exemplos de código.

Exemplos demonstrando como atualizar os namespaces JNDI de versões anteriores podem ser encontradas aqui: Seção 3.1.8.5, “Exemplos de Namespaces JNDI em Versões Anteriores e a Maneira Como São Especificados no JBoss EAP 6”.

Modifique o Descritor do Arquivo jboss-web.xml

Modifique <jndi-name> para cada <ejb-ref> para usar o novo formato de pesquisa totalmente qualificado JNDI.

Use XDoclet para Mapear o Nome JNDI de Interfaces Locais Internas

No EJB 2, era bastante comum usar o padrão Locator para pesquisar Beans. Se você usava este padrão em seu aplicativo, ao invés de modificar o código do aplicativo, você pode usar XDoclet para gerar um mapa para os novos nomes JNDI.

Uma típica anotação XDoclet parece com o seguinte:

@ejb.bean name="UserAttribute" display-name="UserAttribute" local-jndi-name="ejb21/UserAttributeEntity" view-type="local" type="CMP" cmp-version="2.x" primkey-field="id"

O nome JNDI ejb21/UserAttributeEntity no exemplo acima não é mais válido no JBoss EAP 6. Você pode mapear este nome para um nome JNDI usando o subsistema naming na configuração do servidor e um patch para XDoclet.

Mapeadores personalizados podem ser criados conforme mencionado no parágrafo acima entitulado CMP Customized Mappers for Custom Fields ou você pode modificar o código conforme descrito no procedimento a seguir.

Procedimento 3.24. Alteração do Código XDoclet Gerado e Uso do Subsistema de Nomeação

Extraia o template XDoclet lookup.xdt localizado no ejb-module.jar e modifique o lookup() no lookupHome como a seguir:

private static Object lookupHome(java.util.Hashtable environment, String jndiName, Class narrowTo) throws javax.naming.NamingException {  
    // Obtain initial context  
    javax.naming.InitialContext initialContext = new javax.naming.InitialContext(environment);  
    try { 
        // Replace the existing lookup      
        // Object objRef = initialContext.lookup(jndiName);  
        // This is the new mapped lookup
        Object objRef;  
        try {  
            // try JBoss EAP mapping  
            objRef = initialContext.lookup("global/"+jndiName);  
        } catch(java.lang.Exception e) {  
            objRef = initialContext.lookup(jndiName);  
        }  
        // only narrow if necessary  
        if (java.rmi.Remote.class.isAssignableFrom(narrowTo))  
            return javax.rmi.PortableRemoteObject.narrow(objRef, narrowTo); 
        else  
            return objRef;  
    } finally {  
        initialContext.close();  
    }  
}

Execute Ant, configurando o atributo do template para usar o lookup.xdt modificado para a tarefa ejbdoclet.

Modifique o subsistema naming no arquivo de configuração do servidor para mapear o antigo nome JNDI para o novo nome JNDI válido.

<subsystem xmlns="urn:jboss:domain:naming:1.2">  
    <bindings>  
        <lookup name="java:global/ejb21/UserAttributeEntity" lookup="java:global/ejb2CMP/ejb/UserAttribute!de.wfink.ejb21.cmp.cmr.UserAttributeLocalHome"/>  
    </bindings>  
    <remote-naming/>  
</subsystem>

Sumário dos Arquivos Obsoletos

Os seguintes arquivos não possuem mais suporte no JBoss EAP 6.

jboss.xml: O arquivo do descritor de implantação jboss.xml não possui mais suporte e será ignorado caso seja incluído no arquivo implantado.
standardjbosscmp-jdbc.xml: O arquivo de configuração standardjbosscmp-jdbc.xml não possui mais suporte. Esta informação de configuração é agora incluída no módulo org.jboss.as.cmp e não pode mais ser personalizada.
standardjboss.xml: O arquivo de configuração standardjboss.xml não possui mais suporte. A informação de configuração é agora incluída no arquivo standalone.xml, quando executando um servidor autônomo, ou no arquivo domain.xml, quando executando em um domínio gerenciado.

Reportar um erro

3.2.11. Alterações em EJB 2.x

3.2.11.1. Atualização dos Aplicativos que usam EJB 2.x

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Tornando o open source mais inclusivo

Sobre a Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links