Capítulo 5. Alterações na migração dos aplicativos

5.1. Alterações nos aplicativos de serviços Web

JBossWS 5 traz novos recursos e melhorias de desempenho para servidores web JBoss EAP 7, principalmente através de atualizações de componentes Apache CXF, Apache WSS4J e Apache Santuario .

5.1.1. Alterações de suporte JAX-RPC

A API Java para RPC baseado em XML(JAX-RPC) foi preterida no Java EE 6 e é opcional no Java EE 7. Ela não está mais disponível ou suportada no JBoss EAP 7. Aplicativos que utilizam JAX-RPC devem ser migrados para utilizar JAX-WS, que é a atual framework de serviços web padrões Java EE.

A utilização dos serviços web JAX-RPC pode ser identificada em qualquer uma das seguintes maneiras:

  • A presença de um arquivo de mapeamento JAX-RPC, que é um arquivo XML com o elemento raiz <java-wsdl-mapping>.
  • A presença de um arquivo descritor XML webservices.xml que contém um elemento <webservice-description>, que inclui um elemento dependente <jaxrpc-mapping-file>. Segue um exemplo de arquivo descritor webservices.xml que define um serviço web JAX-RPC.

    <webservices xmlns="http://java.sun.com/xml/ns/j2ee"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://www.ibm.com/webservices/xsd/j2ee_web_services_1_1.xsd" version="1.1">
      <webservice-description>
        <webservice-description-name>HelloService</webservice-description-name>
        <wsdl-file>WEB-INF/wsdl/HelloService.wsdl</wsdl-file>
        <jaxrpc-mapping-file>WEB-INF/mapping.xml</jaxrpc-mapping-file>
        <port-component>
          <port-component-name>Hello</port-component-name>
          <wsdl-port>HelloPort</wsdl-port>
          <service-endpoint-interface>org.jboss.chap12.hello.Hello</service-endpoint-interface>
          <service-impl-bean>
            <servlet-link>HelloWorldServlet</servlet-link>
          </service-impl-bean>
        </port-component>
      </webservice-description>
    </webservices>
  • A presença de um arquivo ejb-jar.xml, que contém um <service-ref> que referencia um arquivo de mapeamento JAX-RPC.

5.1.2. Alterações dos serviços web Apache CXF Spring

Em versões prévias do JBoss EAP, você podia personalizar a integração do JBossWS e Apache CXF ao incluir um arquivo de configuração jbossws-cxf.xml com o arquivo de implementação de ponto de extremidade. Um caso de utilização para isto era configurar correntes de interceptores para cliente de serviço web e pontos de extremidades de servidores no barramento Apache CXF. Esta integração exigia a implantação de Spring no servidor JBoss EAP.

A integração do Spring não é mais suportada no JBoss EAP 7. Qualquer aplicativo que contiver um arquivo de configuração de descritor jbossws-cxf.xml deve ser modificado para substituir a configuração personalizada definida naquele arquivo. Embora ainda seja possível acessar diretamente a API Apache CXF, fique ciente de que o aplicativo não será portátil.

A abordagem sugerida é para substituir configurações personalizadas de Spring com as novas opções de configuração de descritor JBossWS quando possível. A abordagem baseada em descritor JBossWS fornece funcionalidade similar sem exigir modificação do código de ponto de extremidade do cliente. Em alguns casos, você pode substituir Spring por Context Dependency Injection (CDI).

Interceptores Apache CXF

O descritor JBossWS fornece novas opções de configurações que permitem a você declarar os interceptores sem modificar o código de ponto de extremidade do cliente. Alternativamente, você declara interceptores dentro de clientes pré-definidos e configurações de pontos de extremidade ao especificar uma lista de nomes de classe de interceptor para as propriedades cxf.interceptors.in e cxf.interceptors.out.

Segue um exemplo de um arquivo jaxws-endpoint-config.xml que declara interceptores usando estas propriedades.

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointImpl</config-name>
    <property>
      <property-name>cxf.interceptors.in</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointInterceptor,org.jboss.test.ws.jaxws.cxf.interceptors.FooInterceptor</property-value>
    </property>
    <property>
      <property-name>cxf.interceptors.out</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointCounterInterceptor</property-value>
    </property>
  </endpoint-config>
</jaxws-config>
Recursos Apache CXF

O descritor JBossWS permite que você declare recursos dentro do cliente pré-definido e configurações de ponto de extremidade ao especificar uma lista de nomes de classe de recursos para a propriedade cxf.features.

Segue um exemplo de um arquivo jaxws-endpoint-config.xml que declara um recurso usando esta propriedade.

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>Custom FI Config</config-name>
    <property>
      <property-name>cxf.features</property-name>
      <property-value>org.apache.cxf.feature.FastInfosetFeature</property-value>
    </property>
  </endpoint-config>
</jaxws-config>
Apache CXF HTTP Transport

Em Apache CXF, a configuração do transporte HTTP é alcançada ao especificar opções org.apache.cxf.transport.http.HTTPConduit. A Integração JBossWS permite que conduits sejam modificados programaticamente usando a API Apache CXF como segue.

import org.apache.cxf.frontend.ClientProxy;
import org.apache.cxf.transport.http.HTTPConduit;
import org.apache.cxf.transports.http.configuration.HTTPClientPolicy;

// Set chunking threshold before using a JAX-WS port client
...
HTTPConduit conduit = (HTTPConduit)ClientProxy.getClient(port).getConduit();
HTTPClientPolicy client = conduit.getClient();

client.setChunkingThreshold(8192);
...

Você pode também controlar e substituir os valores padrão Apache CXF HTTPConduit ao definir as propriedades de sistema.

PropriedadeTipoDescrição

cxf.client.allowChunking

Boolean

Especifica se envia uma solicitações usando agrupamento

cxf.client.chunkingThreshold

Integer

Define o limite no qual é feita a alteração do modo sem agrupamento para o modo de agrupamento.

cxf.client.connectionTimeout

Long

Define o número de milissegundos de tempo limite da conexão.

cxf.client.receiveTimeout

Long

Define o número de milissegundos para expirar a recepção.

cxf.client.connection

String

Especifica a utilização do tipo de conexão Keep-Alive ou close.

cxf.tls-client.disableCNCheck

Boolean

Especifica a desativação da verificação de nome de host CN.

5.1.3. Alterações WS-Security

  • Se seu aplicativo contém um manipulador de retorno de chamada personalizado que acessa a classe org.apache.ws.security.WSPasswordCallback, sabia que esta classe foi transferida para o pacote org.apache.wss4j.common.ext.
  • A maior parte dos objetos bean SAML do pacote org.apache.ws.security.saml.ext foi transferida para o pacote org.apache.wss4j.common.saml package.
  • O uso de transporte de chave RSA v1.5 e todos dos algoritmos relacionados não são permitidos por padrão.
  • Anteriormente, o Security Token Service (STS) validava somente tokens onBehalfOf. Agora também valida tokens ActAs. Como consequência, um nome de usuário válido e senha devem ser especificados no UsernameToken que é fornecido para o token ActAs.
  • Agora os tokens SAML Bearer são exigidos para ter uma assinatura interna. Agora a classe org.apache.wss4j.dom.validate.SamlAssertionValidator tem um método setRequireBearerSignature() para habilitar ou desabilitar a verificação de assinatura.

5.1.4. Alterações de estruturas de módulos JBoss

Os Jars cxf-api e cxf-rt-core foram agrupados em um JAR cxf-core. Como consequência, o módulo org.apache.cxf no JBoss EAP agora contém o JAR cxf-core e expõe mais classes que o lançamento anterior.

5.1.5. Alterações e requisitos de Bouncy Castle

Se você quiser usar criptografia AES com Galois/Counter Mode (GCM) para criptografia simétrica em XML/WS-Security, você precisa do provedor de segurança BouncyCastle.

JBoss EAP 7 envia com módulo org.bouncycastle e JBossWS agora pode confiar em seus carregadores de classes para obter e usar o provedor de segurança BouncyCastle. Portanto, não é mais necessário instalar estaticamente BouncyCastle em JVM atual. Para aplicativos executando fora do contêiner, o fornecedor de segurança pode ser disponibilizado para JBossWS ao adicionar uma biblioteca BouncyCastle ao caminho da classe.

Você pode desativar este comportamento ao configurar o valor de propriedade org.jboss.ws.cxf.noLocalBC para true no arquivo descritor de implementação jaxws-endpoint-config.xml para o servidor ou no arquivo do descritor jaxws-client-config.xmlpara clientes.

Se você quiser uma versão diferente daquela que é enviada com o JBoss EAP, você ainda pode instalar estaticamente o BouncyCastle para a JVM. Neste caso, o provedor de segurança BouncyCastle é escolhido entre o provedor presente no caminho da classe. Para evitar quaisquer problemas, você deve usar BouncyCastle 1.49, 1.51 ou versão superior.

5.1.6. Estratégia de seleção de barramento Apache CXF

A estratégia de seleção do barramento padrão para clientes executando dentro de contêiner mudou de THREAD_BUS para TCCL_BUS. Para clientes executando fora de contêiner, a estratégia padrão ainda é THREAD_BUS. Você pode restaurar o comportamento para o lançamento anterior ao utilizar um dos seguintes métodos.

  • Inicialize o servidor JBoss EAP com o valor da propriedade de sistema org.jboss.ws.cxf.jaxws-client.bus.strategy definido para THREAD_BUS.
  • Defina explicitamente a estratégia de seleção no código do cliente.

5.1.7. Requisitos JAX-WS 2.2 para WebServiceRef

Contêiner deve usar construtores de estilo JAX-WS 2.2, usando a classeWebServiceFeature para compilar clientes que são injetados nas referências do web service. Isto significa que as classes de serviço fornecidas por usuários injetadas pelo contêiner devem implementar JAX-WS 2.2 ou versão superior.

5.1.8. Alterações de verificação CN IgnoreHttpsHost

Em lançamentos prévios, você podia desativar a verificação do nome de host de URL HTTPS com o nome comum (CN - Common Name) do serviço fornecido em seu certificado ao definir a propriedade de sistema org.jboss.security.ignoreHttpsHost para true. Este nome de propriedade de sistema foi substituído por cxf.tls-client.disableCNCheck.

5.1.9. Configuração lado cliente e carregamento de classe

As a consequence of enabling injections into service endpoint and service client handlers, it is no longer possible to automatically load handler classes from the org.jboss.as.webservices.server.integration JBoss module. If your application depends on a given predefined configuration, you might need to explicitly define new module dependencies for your deployment. For more information, see Migrate Explicit Module Dependencies

5.1.10. O mecanismo de substituição de standards endossados Java está descontinuado.

O mecanismo de substituição de standards endossados Java https://docs.oracle.com/javase/8/docs/technotes/guides/standards/ foi descontinuado no JDK 1.8_40 com a intenção de removê-lo no JDK 9. Este mecanismo permite desenvolvedores disponibilizar bibliotecas para todos os aplicativos implantados ao colocar JARs em um diretório endossado dentro do JRE.

Se seu aplicativo utiliza implementações JBossWS de Apache CXF, o JBoss EAP 7 assegura que as dependências necessárias sejam adicionadas na ordem correta e esta alteração não deve causar impacto para você. Se seu aplicativo acessa Apache CXF diretamente, você deve fornecer agora as dependências Apache CXF depois das dependências JBossWS como parte da implantação de seu aplicativo.

5.1.11. Especificação de descritor no arquivo EAR

Em lançamentos prévios do JBoss EAP, era possível configurar o arquivo de descritor de implantação jboss-webservices.xml para implantações de servidor web EJB no diretório META-INF/ dos arquivos JAR ou no diretório WEB-INF/ para implantações de serviço web POJO e pontos de extremidades de serviço web EJB agrupados em arquivos WAR.

Agora no JBoss EAP 7, você pode configurar o arquivo de descritor de implantação jboss-webservices.xml no diretório META-INF/ de um arquivo EAR. Caso um arquivo jboss-webservices.xml for encontrado em ambos os arquivos EAR e o JAR ou arquivo WAR, os dados de configuração no arquivo jboss-webservices.xml para o JAR ou WAR substitui os dados correspondentes no arquivo descritor EAR.

5.2. Atualize a porta e conector URL remoto

No JBoss EAP 7, o conector padrão foi alterado de remoto para http-remoting e a porta de conexão remota padrão foi alterada de 4447 para 8080. O URL do fornecedor JNDI para a configuração padrão foi alterado de remote://localhost:4447 para http-remoting://localhost:8080.

If you use the JBoss EAP 7 migrate operation to update your configuration, you do not need to modify the remote connector, remote port, or JNDI provider URLs because the migration operation preserves the JBoss EAP 6 remoting connector and 4447 port configuration settings in the subsystem configuration. For more information about the migrate operation, see Management CLI Migration Operation.

Se você não usar a operação migrate e em vez disso executar com a configuração padrão nova do JBoss EAP 7, você deve alterar o conector remoto, porta remota e URL do fornecedor JNDI para usar as novas definições conforme descrito acima.

5.3. Alterações de aplicativos de mensagens

5.3.1. Substituir ou atualizar descritores de implantação JMS

Os arquivos de descritores de implantação de recursos JMS proprietários identificados pelo modelo de nomenclatura -jms.xml são obsoletos no JBoss EAP 7. Segue um exemplo de um arquivo de descritor de implantação de recurso JMS no JBoss EAP 6.

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0">
  <hornetq-server>
    <jms-destinations>
      <jms-queue name="testQueue">
        <entry name="queue/test"/>
        <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <entry name="topic/test"/>
        <entry name="java:jboss/exported/jms/topic/test"/>
      </jms-topic>
    </jms-destinations>
  </hornetq-server>
</messaging-deployment>

Se você usou descritores de implantação JMS -jms.xml em seu aplicativo em lançamentos prévios, você pode converter seu aplicativo para usar o descritor de implantação Java EE 7 padrão, conforme especificado na seção EE.5.18 da especificação Java EE 7, ou você pode atualizar o descritor de implantação para usar o subsistema messaging-activemq no JBoss EAP 7.

Se você escolher atualizar o descritor, você precisa fazer as seguintes modificações.

  • Altere o espaço de nomes de "urn:jboss:messaging-deployment:1.0" para "urn:jboss:messaging-activemq-deployment:1.0".
  • Mude o nome do elemento <hornetq-server> para <server>.

O arquivo modificado deve parecer com o exemplo que segue.

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-activemq-deployment:1.0">
  <server>
    <jms-destinations>
      <jms-queue name="testQueue">
        <entry name="queue/test"/>
        <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <entry name="topic/test"/>
        <entry name="java:jboss/exported/jms/topic/test"/>
      </jms-topic>
    </jms-destinations>
  </server>
</messaging-deployment>

Para informação sobre alterações de configuração de servidor relacionadas a mensagens, consulte Alterações de configuração de servidor de mensagens.

5.3.2. Atualizar clientes externo JMS

JBoss EAP 7 ainda suporta API JMS 1.1, assim você não precisa modificar seu código.

O conector remoto padrão e porta foram alterados no JBoss EAP 7. Para detalhes sobre esta mudança, consulte Atualize o conector URL remoto e porta.

Se você migrar sua configuração de servidor usando a operação migrate, as configurações antigas são preservadas e você não precisa atualizar seu PROVIDER_URL. Porém, se você executar com a configuração padrão nova do JBoss EAP 7, você deve alterar o PROVIDER_URL no código do cliente para usar a nova configuração http-remoting://localhost:8080. Para mais informações, consulte Migrar a designação de código de cliente remoto.

Se você planeja migrar seu código para usar a API JMS 2.0, consulte o início rápido helloworld-jms para um exemplo prático.

5.3.3. Substitua a API HornetQ

O JBoss EAP 6 incluía o módulo org.hornetq, que permitia que você usasse API HornetQ no código de fonte de seu aplicativo.

Apache ActiveMQ Artemis substitui HornetQ no JBoss EAP 7, por isso você deve migrar qualquer código que utilizava API HornetQ para utilizar API Apache ActiveMQ Artemis . As bibliotecas para esta API estão incluídas no módulo org.apache.activemq.artemis.

ActiveMQ Artemis é uma evolução do HornetQ, por isso muitos conceitos ainda são válidos.

5.4. Alterações de aplicativos JAX-RS e RESTEasy

Os lançamentos prévios do JBoss EAP agrupava RESTEasy 2, que era uma implementação do JAX-RS 1.x. O JBoss EAP 7 inclui RESTEasy 3, que é uma implementação do JAX-RS 2.0 conforme definido pelo JSR 339: JAX-RS 2.0: A API Java para especificações RESTful Web Services. Para mais informações sobre API Java para RESTful Web Services, consulte a Especificação de API JAX-RS 2.0.

A versão de Jackson incluída no JBoss EAP foi alterada. A versão anterior do JBoss EAP incluía Jackson 1.9.9. O JBoss EAP 7 inclui agora Jackson 2.6.3 ou superior.

This section describes how these changes might impact applications that use RESTEasy or JAX-RS.

5.4.1. Classes preteridas de RESTEasy

Classes de corpo de mensagem e interceptores

JSR 311: JAX-RS: A API Java™ para RESTful Web Services não incluía uma framework de interceptor, por isso RESTEasy 2 forneceu uma. JSR 339: JAX-RS 2.0: A API Java para RESTful Web Services introduziu um interceptor oficial e frameworkd de filtro, por isso a framework do interceptor incluída no RESTEasy 2 está agora preterida e foi substituída pelo interceptor compatível JAX-RS 2.0 no RESTEasy 3.x. As interfaces relevantes estão definidas no pacote javax.ws.rs.ext do módulo jaxrs-api.

Nota

Todos interceptores de lançamentos prévios do RESTEasy podem executar em paralelo com o novo filtro JAX-RS 2.0 e interfaces de interceptor.

For more information about interceptors, see RESTEasy Interceptors in Developing Web Services Applications for JBoss EAP.

Para mais informações sobre a nova API de substituição, consulte RESTEasy JAX-RS 3.0.13.Final API ou mais recente.

API Cliente

A framework do cliente RESTEasy de resteasy-jaxrs foi substituída pelo módulo resteasy-client compatível a JAX-RS 2.0. Sendo assim, algumas classes e métodos de API do cliente RESTEasy são preteridos.

Nota

Para mais informações sobre classes de API org.jboss.resteasy.client.jaxrs , consulte RESTEasy JAX-RS JavaDoc.

StringConverter

A classe org.jboss.resteasy.spi.StringConverter está preterida em RESTEasy 3.x. Esta funcionalidade pode ser substituída usando a classe JAX-RS 2.0 jax.ws.rs.ext.ParamConverterProvider.

5.4.2. Classes de RESTEasy removidas ou protegidas

Métodos de adição de ResteasyProviderFactory

A maior parte de métodos org.jboss.resteasy.spi.ResteasyProviderFactory add() foi removida ou protegida do RESTEasy 3.0. Por exemplo, os métodos addBuiltInMessageBodyReader() e addBuiltInMessageBodyWriter() foram removidos e os métodos addMessageBodyReader() e addMessageBodyWriter() foram protegidos.

Agora, você deve usar os métodos registerProvider() e registerProviderInstance().

Classes suplementares removidas do RESTEasy 3

A anotação @org.jboss.resteasy.annotations.cache.ServerCached, que especificava a resposta para o método JAX-RS deve ser memorizada no servidor, foi removida do RESTEasy 3 e deve ser removida do código do aplicativo.

5.4.3. Outras alterações de RESTEasy

SignedInput e SignedOuput
  • SignedInput e SignedOutput para resteasy-crypto deve ter Content-Type configurado para multipart/signed no objeto Request ou Response, ou usar as anotações @Consumes ou @Produces.
  • SignedOutput e SignedInput podem ser usados para retornar o formato tipo MIME application/pkcs7-signature em forma binária ao definir este tipo nas anotações @Produces ou @Consumes.
  • Se @Produces ou @Consumes forem tipo MIME text/plain, SignedOutput será codificado em base64 enviado como um cadeia.
Filtros de segurança

Os filtros de segurança para @RolesAllowed, @PermitAll e @DenyAll agora retornam "403 Forbidden" ao invés de "401 Unauthorized".

Filtros do lado do cliente

Os novos filtros JAX-RS 2.0 lado cliente não serão limitados e executarão quando você estiver usando a API de cliente RESTEasy a partir de um lançamento prévio.

Suporte HTTP assíncrono

Because the JAX-RS 2.0 specification adds asynchronous HTTP support using the @Suspended annotation and the AsynResponse interface, the RESTEasy proprietary API for asynchronous HTTP has been deprecated and might be removed as soon as RESTEasy 3.1. The asynchronous Tomcat and asynchronous JBoss Web modules have also been removed from the server installation. If you are not using the Servlet 3.0 container or higher, asynchronous HTTP server-side processing will be simulated and run synchronously in same request thread.

Cache do lado do servidor

A configuração da cache do lado do servidor foi alterada. Por favor, consulte a Documentação RESTEasy para mais informações.

5.4.4. Alterações SPI RESTEasy

Exceções SPI

Todas exceções de falhas SPI foram preteridas e não são mais utilizadas internamente. Elas foram substituídas com a exceção JAX-RS 2.0 correspondente.

Exceção preteridaExceção de substituição do módulo jaxrs-api

org.jboss.resteasy.spi.ForbiddenException

javax.ws.rs.ForbiddenException

org.jboss.resteasy.spi.MethodNotAllowedException

javax.ws.rs.NotAllowedException

org.jboss.resteasy.spi.NotAcceptableException

javax.ws.rs.NotAcceptableException

org.jboss.resteasy.spi.NotFoundException

javax.ws.rs.NotFoundException

org.jboss.resteasy.spi.UnauthorizedException

javax.ws.rs.NotAuthorizedException

org.jboss.resteasy.spi.UnsupportedMediaTypeException

javax.ws.rs.NotSupportedException

InjectorFactory e Registro

As SPIs InjectorFactory e Registry foram alteradas. Isto não deve ser um problema se você usar RESTEasy conforme documentado e suportado.

5.4.5. Alterações do provedor Jackson

A versão de Jackson incluída no JBoss EAP foi alterada. A versão anterior do JBoss EAP incluía Jackson 1.9.9. O JBoss EAP 7 inclui agora Jackson 2.6.3 ou superior. Como resultado, o provedor Jackson foi alterado de resteasy-jackson-provider para resteasy-jackson2-provider

A atualização para o resteasy-jackson2-provider requer algumas alterações de pacotes. Por exemplo, o pacote de anotações Jackson foi alterado de org.codehaus.jackson.annotate para com.fasterxml.jackson.annotation.

To switch your application to use the default provider that was included in the previous release of JBoss EAP, see Switching the Default Jackson Provider in Developing Web Services Applications for JBoss EAP.

5.4.6. Alterações à integração de Spring RESTEasy

A framework de Spring 4.0 introduziu suporte para Java 8. Se você planeja usar integração RESTEasy 3.x com Spring, certifique-se que especificou 4.2.x como a versão mínima para Spring em sua implantação pois esta é a versão estável mais recente suportada pelo JBoss EAP 7.

5.4.7. Alterações ao fornecedor RESTEasy Jettison JSON

O fornecedor RESTEasy Jettison JSON é preterido no JBoss EAP 7 e não é mais adicionado às implantações por padrão. Aconselhamos que troque para o fornecedor recomendado RESTEasy Jackson. Se preferir continuar a utilizar o fornecedor Jettison, você deve definir uma dependência explicita para ele no arquivo jboss-deployment-descriptor.xml como demonstrado no seguinte exemplo.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
  <deployment>
    <exclusions>
      <module name="org.jboss.resteasy.resteasy-jackson2-provider"/>
      <module name="org.jboss.resteasy.resteasy-jackson-provider"/>
    </exclusions>
    <dependencies>
      <module name="org.jboss.resteasy.resteasy-jettison-provider" services="import"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

For more information about how to define explicit dependencies, see Add an Explicit Module Dependency to a Deployment in the JBoss EAP Development Guide.

5.5. Alterações aos aplicativos CDI 1.2

JBoss EAP 7 includes support for CDI 1.2. As a result, applications written using CDI 1.0 might see some changes in behavior when migrated to JBoss EAP 7. This section summarizes only a few of those changes.

Você pode encontrar mais informações sobre Weld e CDI 1.2 nas seguintes referências:

Arquivos Bean

As classes Bean de beans ativos devem ser implantadas nos arquivos bean para certificarmos de que estão escaneados pelo CDI para achar e processar as classes bean.

Em CDI 1.0, um arquivo era definido como um arquivo bean explicit se contivesse um arquivo beans.xml no diretório META-INF/ para um aplicativo cliente, EJB ou biblioteca JAR; ou se contivesse um arquivo beans.xml no diretório WEB-INF/ para um WAR.

CDI 1.1 introduziu arquivos bean implicit, que são arquivos que contêm uma ou mais classes de bean com uma anotação de definição de bean, ou uma ou mais sessões beans. Arquivos beans implícitos são escaneados por CDI e, durante o descobrimento do tipo, somente classes com anotações de definição bean são descobertas. Para mais informações, consulte Descoberta de Bean e tipo em Injeção de dependências e contextos para plataforma Java EE.

Um arquivo bean possui modos de descobertas de bean all, annotated ou none. Um arquivo bean que contém um arquivo beans.xml sem versão tem um modo de descoberta de bean padrão all. Um arquivo bean que contém um arquivo beans.xml com versão 1.1 ou mais recente deve especificar o atributo bean-discovery-mode. O valor padrão para o atributo é annotated.

Um arquivo não é um arquivo bean nos seguintes casos:

  • Contiver um arquivo beans.xml com um bean-discovery-mode de none.
  • Contiver uma extensão CDI sem arquivo beans.xml.

Um arquivo é um arquivo bean explicit nos seguintes casos:

  • A pasta de arquivos contém um arquivo beans.xml com um número de versão 1.1 ou mais recente e um bean-discovery-mode de all.
  • A pasta de arquivos contém um arquivo beans.xml sem número de versão.
  • A pasta de arquivos contém um arquivo beans.xml vazio.

Um arquivo é um arquivo bean implicit nos seguintes casos:

  • O arquivo contém uma ou mais classes de bean com uma anotação de definição de bean ou uma ou mais sessões de beans, mesmo que não contenha um arquivo beans.xml.
  • A pasta de arquivo contém um arquivo beans.xml com um bean-discovery-mode de annotated.

CDI 1.2 limitava anotações de definição de bean para o seguinte:

  • Anotações @ApplicationScoped, @SessionScoped, @ConversationScoped e @RequestScoped
  • Todos os outros tipos de escopos normais.
  • Anotações @Interceptor e @Decorator
  • Todas as anotações de esteriótipos, que são anotações anotadas com @Stereotype
  • Anotações de escopo @Dependent

Para mais informações sobre os arquivos bean, consulte Arquivos Bean em Contextos e injeções de dependências para a plataforma Java EE .

Esclarecimento de resolução de conversação

O ciclo de vida de contexto de conversação foi alterado para prevenir conflitos com as especificações do Servlet conforme descrito em Problema de especificação CDI-411. O escopo de conversação está ativo durante todas as requisições servlet e não deve impedir que outros servlets ou filtros de servlet definam o corpo da requisição ou codificação do caractere.

Resolução por observação

A resolução de evento foi parcialmente reescrita em CDI 1.2. Em CDI 1.0, um evento é entregue a um método de observação se o método de observação possui todos os qualificadores de evento. Em CDI 1.2, um evento é entregue a um método de observação se o método de observação não possui qualificadores de evento ou possui um subconjunto dos qualificadores de evento.

5.6. Migrar as dependências de módulo explicito

A introdução de sistema de carregamento de classe modular e JBoss Modules nos lançamentos prévios do JBoss EAP permitiam controle de alta granularidade das classes disponíveis para aplicativos. Este recurso permitia que você configurasse dependências de módulo explícito usando o arquivo MANIFEST.MF do aplicativo ou o arquivo descritor de implantação jboss-deployment-structure.xml.

Se você definiu dependências de módulo explícito em seu aplicativo, você deve estar ciente das seguintes alterações no JBoss EAP 7.

Verifique dependências para disponibilidade

Os módulos que estão incluídos no JBoss EAP foram alterados. Quando você migrar seu aplicativo para JBoss EAP 7, verifique suas entradas de arquivo MANIFEST.MF e jboss-deployment-structure.xml para certificar-se de que elas não se referem a nenhum módulo que foi removido neste lançamento de produto.

Dependências que requerem scan de anotação

No lançamento prévio do JBoss EAP, caso sua dependência contivesse anotações que precisavam ser processadas durante o scan de anotação, por exemplo quando declarando interceptadores EJB, era solicitado que você gerasse e incluísse um índice Jandex em um novo arquivo JAR e depois definisse um sinalizador no arquivo descritor de implantação MANIFEST.MF ou jboss-deployment-structure.xml.

Agora JBoss EAP 7 oferece geração de tempo de execução automática de índices de anotação para módulos estáticos, assim você não precisa mais gerá-los manualmente. Contudo, você ainda precisa adicionar o sinalizador annotations ao arquivo MANIFEST.MF do aplicativo ou o arquivo descritor de implantação jboss-deployment-structure.xml conforme demonstrado abaixo.

Exemplo de sinalizador de anotação no arquivo MANIFEST.MF

Dependências: com.company.my-ejb annotations, com.company.other

Exemplo de sinalizador de anotação no arquivo jboss-deployment-structure.xml

<jboss-deployment-structure>
  <deployment>
    <dependencies>
      <module name="com.company.my-ejb" annotations="true"/>
      <module name="com.company.other"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

5.7. Alterações de migração JPA e Hibernate

5.7.1. Hibernate ORM 3.0

As classes de integração que facilitaram a utilização do Hibernate ORM 3 em lançamentos prévios foram removidas do JBoss EAP 7. Se seu aplicativo ainda utiliza bibliotecas do Hibernate ORM 3, é altamente recomendável que você migre seu aplicativo para utilizar Hibernate ORM 5 pois Hibernate ORM 3 não funcionará mais em JBoss EAP facilmente. Se você não pode migrar para Hibernate ORM 5, você deve definir um módulo JBoss personalizado para os JARs de Hibernate ORM 3 e excluir as classes de Hibernate ORM 5 de seu aplicativo.

5.7.2. Hibernate ORM 4.0 - 4.3

Caso seu aplicativo necessite que o cache de segundo nível seja ativado, você deve migrar para Hibernate ORM 5.0, que é integrado com Infinispan 8.x.

Aplicativos escritos com Hibernate ORM 4.x ainda podem usar Hibernate 4.x. Você deve definir um módulo JBoss personalizado para os JARs Hibernate 4.x e excluir as classes Hibernate 5 de seu aplicativo. Contudo, é altamente recomendável que você reescreva o código de seu aplicativo para usar Hibernate 5. Para information sobre como migrar para Hibernate ORM 5, consulte Migrating to Hibernate ORM 5.

5.7.3. Hibernate ORM 5

Caso seu aplicativo contiver um arquivo persistence.xml ou o código usa anotações @PersistenceContext ou @PersistenceUnit, JBoss EAP 7 detecta isto durante a implantação e presume que o aplicativo usa JPA. As bibliotecas Hibernate ORM 5.O são implicitamente adicionadas, assim como algumas outras dependências, ao caminho de classe de seu aplicativo e estas bibliotecas são usadas por padrão.

5.7.4. Migrando para Hibernate ORM 5

Esta seção destaca as alterações que você precisa fazer quando migrar do Hbernate ORM versão 4.3 para versão 5. Para mais informações sobe as alterações implementadas entre o Hibernate ORM 4 e Hibernate ORM 5, consulte o Guia de migração Hibernate ORM 5.0.

Classes preteridas e excluídas

The following deprecated classes were removed from Hibernate ORM 5.

Outras alterações às classes e pacotes
Type Handling
  • Implementações incorporadas org.hibernate.type.descriptor.sql.SqlTypeDescriptor não mais se auto registrarão com org.hibernate.type.descriptor.sql.SqlTypeDescriptorRegistry. Os aplicativos utilizando implementações personalizadas SqlTypeDescriptor que estendem as implementações incorporadas e apóiam-se neste comportamento devem ser atualizadas para chamarem-se SqlTypeDescriptorRegistry.addDescriptor().
  • Para IDs definidas como UUIDs geradas, alguns bancos de dados precisavam que você definisse explicitamente o @Column(length=16) para gerar o BINARY(16) para que as comparações funcionem adequadamente.
  • Para mapeamento tipo Enum definido em hbm.xml, onde você deseja javax.persistence.EnumType.STRING name-mapping, esta configuração deve ser declarada explicitamente ao usar definição useNamed(true) ou ao especificar um VARCHAR valor de 12.
Gerenciamento de transação.
  • A IDA de transação passou por uma reformulação considerável no Hibernate ORM 5. Em Hibernate ORM 4.3, você utilizava a API org.hibernate.Transaction para acessar diretamente estratégias de transações back-end. Hibernate ORM 5 introduziu um nível de indireção. No back end, a implementação org.hibernate.Transaction agora conversa com um org.hibernate.resource.transaction.TransactionCoordinator, que representa o contexto transacional para uma dada sessão de acordo com a estratégia de back-end. Mesmo que isto não tenha um impacto direto nos desenvolvedores, pode afetar a configuração do bootstrap. Anteriormente, aplicativos especificavam propriedade hibernate.transaction.factory_class, que agora tornou-se preterida, e referiam ao org.hibernate.engine.transaction.spi.TransactionFactory FQN (fully qualified name). Com o Hibernate ORM 5, você especifica a configuração hibernate.transaction.coordinator_class e refere a um org.hibernate.resource.transaction.TransactionCoordinatorBuilder. Veja org.hibernate.cfg.AvailableSettings.TRANSACTION_COORDINATOR_STRATEGY para informações adicionais.
  • Os seguintes nomes curtos são agora reconhecidos.

    • jdbc: Manage transactions using the JDBC java.sql.Connection. This is the default for non-JPA transactions.
    • jta: Manage transactions using JTA.

      Importante

      If a JPA application does not provide a setting for the hibernate.transaction.coordinator_class property, Hibernate will automatically build the proper transaction coordinator based on the transaction type for the persistence unit.

      If a non-JPA application does not provide a setting for the hibernate.transaction.coordinator_class property, Hibernate will default to jdbc to manage the transactions. This default will cause problems if the application actually uses JTA-based transactions. A non-JPA application that uses JTA-based transactions should explicitly set the hibernate.transaction.coordinator_class property value to jta or provide a custom org.hibernate.resource.transaction.TransactionCoordinatorBuilder that builds a org.hibernate.resource.transaction.TransactionCoordinator that properly coordinates with JTA-based transactions.

Outra alteração Hibernate ORM 5
  • Os arquivos cfg.xml são novamente completamente analisados e integrados com eventos, segurança e outras funções.
  • As propriedades carregadas a partir de cfg.xml usando a EntityManagerFactory não colocou prefixos anteriormente com hibernate. Isto tornou-se consistente.
  • A configuração não é serializável.
  • O método org.hibernate.dialect.Dialect.getQuerySequencesString() agora recupera valores de catálogo, esquema e incremento.
  • O modificador AuditConfiguration foi removido de org.hibernate.envers.boot.internal.EnversService.
  • Os parâmetros de método AuditStrategy foram alterados para excluir AuditConfiguration preterido e usar o novo EnversService.
  • Várias classes e interfaces no org.hibernate.hql.spi package and subpackages have been moved to the new org.hibernate.hql.spi.id package. Isto inclui a classe MultiTableBulkIdStrategy e interfaces e suas subclasses AbstractTableBasedBulkIdHandler, TableBasedDeleteHandlerImpl, e TableBasedUpdateHandlerImpl .
  • Houve um redesenho completo de contratos de acesso a propriedade.
  • Valores de definição válidos hibernate.cache.default_cache_concurrency_strategy agora são definidos utilizando o método org.hibernate.cache.spi.access.AccessType.getExternalName() em vez de constantes enum org.hibernate.cache.spi.access.AccessType. Isto é mais consistente com outras definições de Hibernate.

5.8. Alterações no Hibernate Search

A versão do Hibernate Search fornecida com JBoss EAP 7 foi alterada. O lançamento prévio do JBoss EAP fornecia Hibernate Search 4.6.x. O JBoss EAP 7 fornece Hibernate Search 5.5.x.

Hibernate Search 5.5 is built upon Apache Lucene 5.3.1. If you use any native Lucene APIs, be sure to align with this version. The Hibernate Search 5.5 API wraps and hides the complexity of many of the Lucene API changes made between version 3 and version 5, however, some classes are now deprecated, renamed, or repackaged. This section describes how these changes might impact your application code.

Alterações de mapeamento do Hibernate Search

Indexing of id Fields of Embedded Relations

Quando usar uma anotação @IndexedEmbedded para incluir campos de uma entidade relacionada, a id da entidade relacionada não é mais incluída. Você pode ativar a inclusão da id ao usar o atributo includeEmbeddedObjectId da anotação @IndexedEmbedded.

@IndexedEmbedded(includeEmbeddedObjectId=true)
Modificações na formatação do índice de data e número

Agora, números e datas são indexados por padrão como campos numéricos. Propriedades de tipo int, long, float, double, e suas classes encapsuladas correspondentes não são mais indexadas como cadeias. Ao invés, elas são agora indexadas usando codificação Lucene numérica apropriada. Os campos id são é uma exceção a esta regra. Mesmo quando são representados por um tipo numérico, eles ainda são indexados como uma palavra-chave de cadeia por padrão. Agora, o uso de @NumericField é preterido, a não ser que você queira especificar uma precisão personalizada para a codificação numérica. Você pode manter o antigo formato de índice baseado em cadeia ao especificar explicitamente uma ponde de campo de codificação em cadeia. No caso de inteiros, isto é o org.hibernate.search.bridge.builtin.IntegerBridge. Verifique o pacote org.hibernate.search.bridge.builtin para outras pontes de campos acessíveis publicamente.

Data e Calendário não são mais indexados como cadeias. Ao invésdisso, instâncias são codificadas como valores compridos representando o número de milissegundos desde 1 de janeiro de 1970, 00:00:00 GMT. Você pode trocar o formato de indexação ao usar EncodingType enum. Por exemplo:

@DateBridge(encoding=EncodingType.STRING)
@CalendarBridge(encoding=EncodingType.STRING)

A alteração de codificação para números e datas é importante e pode ter um grande impacto no comportamento do aplicativo. Se você tem uma consulta que se destina a um campo que foi previamente codificado em cadeia, mas está agora codificado numericamente, você deve atualizar esta consulta. Campos numéricos devem ser pesquisados com um NumericRangeQuery. Você deve também certificar-se que todos os campos destinados por facetamento são codificados em cadeia. Se você usar a consulta DSL Search, a consulta correta deve ser criada automaticamente para você .

Alterações diversas no Hibernate Search

  • Opções de classificação foram melhoradas e agora codificação de campos especificados incorretamente para opções de classificação resultam em exceções de tempo de execução. Lucene também oferece classificação mais eficaz se os campos utilizados na classificação são conhecidos antecipadamente. Hibernate Search 5.5 fornece uma nova anotação @SortableField e seu companheiro multi-valorizado @SortableFields. Consulte o link Guia de Migração do Hibernate Search 5.4 para 5.5 para mais informações .
  • A API SortField da Lucene requer a seguinte alteração de código de aplicativo.

    No lançamento prévio do JBoss EAP, você definia o tipo do campo de classificação na consulta conforme segue.

    fulltextQuery.setSort(new Sort(new SortField("title", SortField.STRING)));

    O seguinte é um exemplo de como definir no JBoss EAP 7.

    fulltextQuery.setSort(new Sort(new SortField("title", SortField.Type.STRING)));
  • Já que SearchFactory deve ser somente usado por integração ORM, ele foi movido do módulo hibernate-search-engine para o módulo hibernate-search-orm. Outros integradores devem depender exclusivamente em SearchIntegrator, que substitui o preterido SearchFactoryIntegrator.
  • O valor enum SpatialMode.GRID foi renomeado para SpatialMode.HASH.
  • FullTextIndexEventListener agora é uma classe final. Se você atualmente estende esta classe, você deve achar uma solução alternativa para conseguir a mesma funcionalidade.
  • O módulo hibernate-search-analyzers foi removido. A abordagem recomendada é usar diretamente o artefato Lucene apropriado, por exemplo org.apache.lucene:lucene-analyzers-common.
  • The JMS controller API has changed. The JMS back-end dependency on Hibernate ORM was removed so that it could be used in other non-ORM environments. A consequence is that implementors of org.hibernate.search.backend.impl.jms.AbstractJMSHibernateSearchController must adjust to the new signature. This class is an internal class and it is recommended to use it as an example instead of extending it.
  • A SPI org.hibernate.search.spi.ServiceProvider foi refatorada. Se você estava integrando com o contrato de serviço antigo, consulte Hibernate Search 5.5 Javadoc do ServiceManager, Service, Startable e Stoppable para detalhes sobre o novo contrato.
  • Se você manteve índices gerados pelo Lucene 3.x e não os reconstruiu com Hibernate Search 5.0 ou mais recente, você receberá um IndexFormatTooOldException. É recomendado que você reconstrua os índices com o indexador em massa. Se você não pode fazer isto, tente usar o IndexUpgrader do Lucerne. Você deve atualizar cuidadosamente o mapeamento do Hibernate Search caso o comportamento padrão tenha sido alterado. Para mais informações, consulte Guia de migração do Apache Lucene .
  • O Apache Lucene foi atualizado do 3.6 para 5.3 no JBoss EAP 7. Se o seu código importa o código Lucene diretamente, consulte Guia de migração do Apache Lucene para detalhes das alterações. Informações adicionais podem também serem encontradas no Lucene Change Log.
  • Quando usar @Field(indexNullAs=) para codificar um valor de marcação nulo no índice, o tipo de marcação deve ser compatível com todos os outros valores que estão indexados no mesmo campo. Por exemplo, anteriormente, era possível codificar um valor nulo para campos numéricos usando uma cadeia "nula". Isto não é mais possível. Ao invés disso, você deve escolher um número para representar o valor nulo, como por exemplo -1.
  • Foram feitos aprimoramentos significantes ao mecanismo de faceta. A maior parte das alterações não afetam a API. Uma exceção importante é que agora você deve anotar quaisquer campos que pretende usar a faceta com a anotação @Facet ou @Facets.

Classes de Hibernate Search renomeadas e reempacotadas

A lista que segue é uma lista de classes de Hibernate Search que foram reempacotadas ou renomeadas.

Pacote e anterior e classeNovo pacote e classe

org.hibernate.search.Environment

org.hibernate.search.cfg.Environment

org.hibernate.search.FullTextFilter

org.hibernate.search.filter.FullTextFilter

org.hibernate.search.ProjectionConstants

org.hibernate.search.engine.ProjectionConstants

org.hibernate.search.SearchException

org.hibernate.search.exception.SearchException

org.hibernate.search.Version

org.hibernate.search.engine.Version

Lucene - Classes renomeadase reempacotadas

Os analisadores de consultas foram movidos para um novo módulo, resultando em uma alteração de pacotes de org.apache.lucene.queryParser.QueryParser para org.apache.lucene.queryparser.classic.QueryParser.

Vários analisadores Lucene foram refatorados resultando em alterações de pacotes. Consulte Documentação Apache Lucene para procurar pacotes substitutos.

Algumas classes de utilidades Apache Solr, por exemplo TokenizerFactory ou TokenFilterFactory, foram movidas para o Apache Lucene. Caso seu aplicativo usar estas utilidades ou analisadores personalizados, você deve procurar o novo nome de pacote no Apache Lucene.

Consulte o Guia de Migração Apache Lucene para mais informações.

APIs Hibernate Search preteridas

Para a lista completa de interfaces preteridas de Hibernate Search, de classes, de enums, tipos de anotações, métodos, construtores e constantes de enum, consulte o documento Hibernate Search Deprecated API.

Interfaces preteridas de Hibernate Search
InterfaceDescrição

org.hibernate.search.store.IndexShardingStrategy

Preterida desde Hibernate Search 4.4. Pode ser removida em Search 5. Em seu lugar use ShardIdentifierProvider.

org.hibernate.search.store.Workspace

Esta interface será movida e deve ser considerada API não-pública. Para mais informações, vejaHSEARCH-1915.

Classes Hibernate Search preteridas
ClasseDescrição

org.hibernate.search.filter.FilterKey

As chaves de filtragem personalizadas são preteridas e estão programadas para serem removidas em Hibernate Search 6. A partir de Hibernate Search 5.1, as chaves para caching os filtros Lucene são calculadas automaticamente baseando-se nos parâmetros de filtros fornecidos.

org.hibernate.search.filter.StandardFilterKey

As chaves de filtragem personalizadas são preteridas e estão programadas para serem removidas em Hibernate Search 6. A partir de Hibernate Search 5.1, as chaves para caching os filtros Lucene são calculadas automaticamente baseando-se nos parâmetros de filtros fornecidos.

Hibernate Search Deprecated Enums
EnumDescrição

org.hibernate.search.annotations.FieldCacheType

Remova a anotação CacheFromIndex pois é preterida. Consulte Anotações preteridas de Hibernate Search.

Anotações preteridas de Hibernate Search
AnotaçãoDescrição

org.hibernate.search.annotations.CacheFromIndex

Remover anotação. Não é necessário um substituto alternativo.

org.hibernate.search.annotations.Key

As chaves de cache de filtro personalizado são uma funcionalidade preterida e estão programadas para serem removidas em Hibernate Search 6. A partir de Hibernate Search 5.1, as chaves de cache de filtro são definidas automaticamente baseadas nos parâmetros de filtros, portanto não é mais necessário fornecer um objeto chave.

Métodos preteridos de Hibernate Search
MétodoDescrição

org.hibernate.search.FullTextSharedSessionBuilder.autoClose()

Sem substitução

org.hibernate.search.FullTextSharedSessionBuilder.autoClose(boolean)

Sem substitução

org.hibernate.search.cfg.IndexedMapping.cacheFromIndex(FieldCacheType…​)

Isto será removido sem substituição.

org.hibernate.search.cfg.EntityDescriptor.getCacheInMemory()

Isto será removido sem substituição.

org.hibernate.search.cfg.ContainedInMapping.numericField()

Invoke field().numericField() instead.

org.hibernate.search.cfg.EntityDescriptor.setCacheInMemory(Map<String, Object>)

Isto será removido sem substituição.

org.hibernate.search.MassIndexer.threadsForSubsequentFetching(int)

Este método será removido.

org.hibernate.search.query.dsl.FuzzyContext.withThreshold(float)

Utilize FuzzyContext.withEditDistanceUpTo(int).

Construtores preteridos de Hibernate Search
ConstrutorDescrição

org.hibernate.search.cfg.NumericFieldMapping(PropertyDescriptor, EntityDescriptor, SearchMapping)

Utilize NumericFieldMapping.NumericFieldMapping(String, PropertyDescriptor, EntityDescriptor, SearchMapping) em seu lugar.

Alterações que impactam integradores avançados

Esta seção descreve alterações que não fazem parte da API pública. Isto não deve impactar o desenvolvedor comum pois estes artefatos devem ser acessados somente por integradores que estendem a framework Hibernate Search.

5.9. Migrar de beans de entidade para JPA

Suporte para beans de entidade EJB é facultativo em Java EE 7 e não são suportados em JBoss EAP 7. Isto significa que beans de entidade de persistência gerenciada por contêiner (CMP) e persistência gerenciada pelo bean (BMP) devem ser reescritos para usar entidades Java Persistence API (JPA) quando você migrar para JBoss EAP 7.

Nas versões anteriores de JBoss EAP, beans de entidade eram criados em código fonte de aplicativo ao estender a classe javax.ejb.EntityBean e implementar os métodos requeridos. A partir dai, eles eram configurados no arquivo ejb-jar.xml. Um bean de entidade CMP era especificado usando um elemento <entity> que continha um elemento filho <persistence-type> com um valor de Container. Um bean de entidade BMP era especificado usando um elemento <entity> que continha um elemento filho <persistence-type> com um valor de Bean.

EmJBoss EAP 7, você deve substituir quaisquer beans de entidade CMP e BMP em seu código com entidades Java Persistence API (JPA). Entidades JPA são criadas usando as classesjavax.persistence.* e são definidas no arquivo persistence.xml.

O que segue é um exemplo de uma classe de entidade JPA.

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
// User is a keyword in some SQL dialects!
@Table(name = "MyUsers")
public class MyUser {
    @Id
    @GeneratedValue
    private Long id;

    @Column(unique = true)
    private String username;
    private String firstName;
    private String lastName;

    public Long getId() {
        return id;
    }
    public String getUsername() {
        return username;
    }
    public void setUsername(String username) {
        this.username = username;
    }
    public String getFirstName() {
        return firstName;
    }
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

O seguinte é um exemplo de um arquivo persistence.xml.

<persistence version="2.1"
      xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="
        http://xmlns.jcp.org/xml/ns/persistence
        http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
  <persistence-unit name="my-unique-persistence-unit-name">
    <properties>
      // properties...
    </properties>
  </persistence-unit>
</persistence>

Para obter exemplos de entidades JPA, consulte o início rápido bmt, cmt e hibernate5 que fornecido em JBoss EAP 7.

5.10. Alterações de propriedades de persistência JPA

Uma nova propriedade de persistência, jboss.as.jpa.deferdetach, foi adicionada para fornecer compatibilidade com o comportamento de persistência em lançamentos prévios de JBoss EAP.

A propriedade jboss.as.jpa.deferdetach controla se o contexto de persistência transaction-scoped utilizado em uma thread de transação non-JTA desanexa entidades carregadas após cada invocação EntityManager ou se aguarda até que o contexto de persistência esteja fechado, por exemplo, quando é finalizada a sessão de invocação de bean. O valor de propriedade é por padrão false, o que significa que entidades são desanexadas ou removidas após cada invocação EntityManager. Este é o comportamento padrão correto conforme definido em especificação JPA . Caso o valor de propriedade estiver definido para true, as entidade não são desanexadas até que o contexto de persistência esteja fechado.

Em JBoss EAP 5, as persistências comportavam-se como se a propriedade jboss.as.jpa.deferdetach estivesse definida para true. Para obter este mesmo comportamento quando migrar seu aplicativo do JBoss EAP 5 para JBoss EAP 7, você deve definir o valor de propriedade jboss.as.jpa.deferdetach para true em seu persistence.xml conforme explicado no seguinte exemplo.

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
    <persistence-unit name="EAP5_COMPAT_PU">
    <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
    <properties>
         <property name="jboss.as.jpa.deferdetach" value="true" />
    </properties>
  </persistence-unit>
</persistence>

Em JBoss EAP 6, as persistências comportavam-se como se a propriedade jboss.as.jpa.deferdetach estivesse definida para falso. Este é o mesmo comportamento encontrado em JBoss EAP 7, por isso não há necessidades de alterações quando você migrar seu aplicativo.

5.11. Migrar o código de cliente EJB

O conector remoto padrão e porta foram alterados no JBoss EAP 7. Para detalhes sobre esta mudança, consulte Atualize o conector URL remoto e porta.

Se você usou a operação migrate para migrar sua configuração de servidor, as definições antigas são preservadas e você não precisa fazer as alterações detalhadas abaixo. Contudo, se você executa com a nova configuração padrão de JBoss EAP 7, você deve fazer as seguintes alterações.

5.11.1. Atualize a porta de conexão remota padrão

Modifique o valor de porta da conexão remota de 4447 para 8080 no arquivo jboss-ejb-client.properties.

Os exemplos seguintes são de um arquivo jboss-ejb-client.properties na versão antiga e na atual.

Examplo: arquivo JBoss EAP 6 jboss-ejb-client.properties

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

Examplo: arquivo JBoss EAP 7 jboss-ejb-client.properties

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

5.11.2. Atualizar o conector padrão

Se você esta executando com a nova configuração de JBoss EAP 7, o conector padrão foi modificado de remote para http-remoting. Esta alteração impacta clientes que utilizam bibliotecas de uma versão de JBoss EAP para conectar-se ao servidor em uma versão diferente.

  • Se um aplicativo cliente utiliza a biblioteca cliente EJB de JBoss EAP 6 e deseja conectar-se ao servidor JBoss EAP 7, o servidor deve estar configurado para expor um conector remote em uma porta além da 8080. O cliente deve então conectar-se utilizando aquele conector recém-configurado.
  • Um aplicativo cliente que utiliza biblioteca cliente EJB de JBoss EAP 7 e deseja conectar-se ao servidor JBoss EAP 6 deve estar ciente que a instância do servidor não utiliza o conector http-remoting, em vez disto utiliza um conector remote. Isto é realizado ao definir uma nova propriedade de conexão lado cliente.

    remote.connection.default.protocol=remote

5.11.3. Migrar código de cliente de nomeação remota

Se você está executando com a nova configuração padrão JBoss EAP 7, você deve modificar seu código cliente para usar a nova porta remota padrão e conector.

O exemplo seguinte é de como propriedades de nomeação remota foram especificadas no código cliente no JBoss EAP 6.

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=remote://localhost:4447

O exemplo seguinte é de como especificar as propriedades de nomeação remota no código cliente no JBoss EAP 7.

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=http-remoting://localhost:8080

5.12. Migrar configurações de planos de implementação

A especificação Java EE Application Deployment (JSR-88) destinava-se a definir um contrato padrão para permitir que ferramentas de vários provedores configurassem e implantarem aplicativos em qualquer produto de plataforma Java EE. O contrato exigia que os provedores de produtos Java EE implementassem as interfaces DeploymentManager e outras interfaces javax.enterprise.deploy.spi para serem acessadas pelos provedores de ferramentas. No caso do JBoss EAP 6, um plano de implementação é identificado por um descritor XML denominado deployment-plan.xml que está incluído em um arquivo ZIP ou JAR.

Esta especificação teve pouca aceitação pois a maioria dos produtos de servidores de aplicativos fornecem suas próprias soluções de implementação mais "ricas em recursos ". Por esta razão, o suporte JSR-88 foi abandonado a partir do Java EE 7, por sua vez, abandonado a partir do JBoss EAP 7.

If you used JSR-88 to deploy your application, you must now use another method to deploy the application. The JBoss EAP management CLI deploy command provides a standard way to deploy archives to standalone servers or to server groups in a managed domain. For more information about the management CLI, see the Management CLI Guide.

5.13. Migrar válvulas de aplicativos personalizadas

Você deve migrar manualmente válvulas personalizadas ou qualquer válvulas que estão definidas no arquivo XMLjboss-web.xml. Isto inclui válvulas criadas ao estender as classes org.apache.catalina.valves.ValveBase e configuradas no elemento <valve> do arquivo descritor jboss-web.xml.

Importante

Válvulas personalizadas e válvulas que são definidas no arquivo jboss-web.xml devem ser regravadas ou substituídas por manipuladores Undertow internos correspondentes. Para informações sobre associação de válvulas ao manipulador Undertow, consulte Migrar válvulas web JBoss .

Válvulas de autenticação devem ser substituídas manualmente usando mecanismos de autenticação internos Undertow.

Migrar válvulas configuradas em implementações

No JBoss EAP 6, você podia definir válvulas personalizadas ao nível de aplicativo ao configurá-las no arquivo descritor de aplicativo web jboss-web.xml. No JBoss EAP 7, é possível fazer isto também com os manipuladores Undertow.

O que segue é um exemplo de uma válvula configurada no arquivo jboss-web.xml no JBoss EAP 6.

<jboss-web>
    <valve>
        <class-name>org.jboss.examples.MyValve</class-name>
​        <param>
    ​        <param-name>myParam</param-name>
​            <param-value>foobar</param-value>
    ​    </param>
    </valve>
</jboss-web>

For more information about how to create and configure custom handlers in JBoss EAP, see Creating Custom Handlers in the JBoss EAP Development Guide.

Migrar válvulas de autenticador personalizadas

Para informação sobre como migrar válvulas de autenticador, consulte Alterações de aplicativos de segurança

5.14. Alterações de aplicativos de segurança

A substituição de JBoss Web com Undertow requer alterações nas configurações de segurança no JBoss EAP 7.

5.14.1. Migrar válvulas do autenticador

As válvulas do autenticador devem ser substituídas manualmente usando o mecanismo de autenticação interno Undertow. Consulte as seções seguintes para informações sobre como migrar válvulas do autenticador.

5.14.3. Outras alterações de aplicativos de segurança

For information about the differences in SSO configuration with Kerberos, see Differences from Configuring Previous Versions JBoss EAP in How to Set Up SSO with Kerberos for JBoss EAP.

5.15. Alterações de JBoss Logging

Se seu aplicativo usa JBoss Logging, esteja ciente de que as anotações no pacote org.jboss.logging agora são preteridas no JBoss EAP 7. Elas foram movidas para o pacote org.jboss.logging.annotations, então você deve atualizar seu código-fonte para importar o novo pacote.

As anotações também foram movidas para um ID de Maven groupId:artifactId:version (GAV) separado, assim você precisa adicionar uma nova dependência de projeto para org.jboss.logging:jboss-logging-annotations em seu arquivo de projeto pom.xml.

Nota

Somente as anotações registradas em log foram movidas. A org.jboss.logging.BasicLogger e org.jboss.logging.Logger ainda existem no pacote org.jboss.logging.

A tabela seguinte lista as classes de anotações preteridas e substituições correspondentes.

Tabela 5.1. Substituições de anotações de registro em log preteridas

Classes preteridas Classes de substituição

org.jboss.logging.Cause

org.jboss.logging.annotations.Cause

org.jboss.logging.Field

org.jboss.logging.annotations.Field

org.jboss.logging.FormatWith

org.jboss.logging.annotations.FormatWith

org.jboss.logging.LoggingClass

org.jboss.logging.annotations.LoggingClass

org.jboss.logging.LogMessage

org.jboss.logging.annotations.LogMessage

org.jboss.logging.Message

org.jboss.logging.annotations.Message

org.jboss.logging.MessageBundle

org.jboss.logging.annotations.MessageBundle

org.jboss.logging.MessageLogger

org.jboss.logging.annotations.MessageLogger

org.jboss.logging.Param

org.jboss.logging.annotations.Param

org.jboss.logging.Property

org.jboss.logging.annotations.Property

5.16. Alterações ao código JavaServer Faces (JSF)

Suporte para JSF 1.2 descontinuado

JBoss EAP 6 permitia que você continuasse a usar JSF 1.2 com sua implementação de aplicativo ao criar um arquivo jboss-deployment-structure.xml.

JBoss EAP 7 inclui JSF 2.2 e não suporta mais a API JSF 1.2. Se seu aplicativo usa JSF 1.2, você deve regravá-lo para usar JSF 2.2.

Problema de compatibilidade entre JSF 2.1 e JSF 2.2

As APIs JSF 2.1 e JSF 2.2 APIs não são totalmente compatíveis. O valor da constante FACELET_CONTEXT_KEY mudou de com.sun.faces.facelets.FACELET_CONTEXT para javax.faces.FACELET_CONTEXT entre os lançamentos. Este valor é inlined pelo compilador e compilador de código para uma versão não funcionará para outra.

Os aplicativos que contém código similar ao exemplo seguinte e são compilados com a API JSF 2.1 mas são executados no JBoss EAP 7 que utiliza a API JSF 2.2, resulta em um NullPointerException. Para corrigir este problema, você deve recompilar o aplicativo com API JSF 2.2.

Object obj = FacesContext.getCurrentInstance().getAttributes().get(FaceletContext.FACELET_CONTEXT_KEY);

Consulte JAVASERVERFACES_SPEC_PUBLIC-1257 para mais informações.

5.17. Alterações ao carregamento de classes de módulos

No JBoss EAP 7, o comportamento do carregamento de classe foi alterado em casos onde múltiplos módulos contêm as mesmas classes ou pacotes.

Presuma que existam dois módulos: MODULE_A e MODULE_B; que dependem uns dos outros e contêm alguns pacotes iguais. No JBoss EAP 6, as classes ou pacotes que eram carregados a partir de dependências sobrepunham-se àqueles especificados no resource-root do arquivo module.xml. Isto significava que MODULE_Avisualizava os pacotes para MODULE_B e MODULE_B visualizava os pacotes para MODULE_A. Este comportamento era confuso e poderia causar conflitos. Este comportamento foi alterado no JBoss EAP 7. Agora as classes ou pacotes especificados pelo resource-root no arquivo module.xml sobrepõem-se àqueles especificados pela dependência. Isto significa que MODULE_A visualiza os pacotes para MODULE_A e MODULE_B visualiza os pacotes para MODULE_B. Isto previne conflitos e proporciona um comportamento mais adequado.

If you have defined custom modules that include resource-root libraries or packages that contain classes that are duplicated in their module dependencies, you might see ClassCastException, LinkageError, class loading errors, or other changes in behavior when you migrate to JBoss EAP 7. To resolve these issues, you must configure your module.xml file to ensure only one version of a class is used. This can be accomplished by using either of the following approaches.

  • Você pode evitar especificar um resource-root que duplica classes em dependências de módulos.
  • Você pode usar os sub-elementos include e exclude dos elementos imports e exports para controlar o carregamento de classe no arquivo module.xml. O que segue é um elemento de exportação que exclui classes nos pacotes especificados.

    <exports>
      <exclude path="com/mycompany/duplicateclassespath/"/>
    </exports>

Se você prefere preservar seu comportamento existente, você deve filtrar os pacotes de dependências da resource-root dependente no arquivo module.xml usando o elemento filter. Isto permitirá que você retenha o comportamento existente sem o looping que você notaria com o JBoss EAP 6. A seguir, veja um exemplo de um root-resource que filtra classes em um pacote especificado.

<resource-root path="mycompany.jar">
  <filter>
    <exclude path="com/mycompany/duplicateclassespath"/>
  </filter>
</resource-root>

For more information about modules and class loading, see Class Loading and Modules in the JBoss EAP Development Guide.

5.18. Alterações à clusterização de aplicativos

5.18.1. Visão geral de novas funcionalidades de clusterização

A lista seguinte descreve algumas das novas funcionalidades de clusterização para considerar quando fizer a migração de seu aplicativo do JBoss EAP 6 para JBoss EAP 7.

  • JBoss EAP 7 introduces a new public API for building singleton services that significantly simplifies the process. For more information, see Implement an HA Singleton in Developing EJB Applications for JBoss EAP.
  • A singleton deployment can be configured to deploy and start on only a single node in the cluster at a time. For more information, see HA Singleton Deployments in the JBoss EAP Development Guide.
  • You can now define clustered singleton MDBs. For more information, see Clustered Singleton MDBs in Developing EJB Applications for JBoss EAP.
  • JBoss EAP 7 includes the Undertow mod_cluster implementation. This offers a pure Java load balancing solution that does not require an httpd web server. For more information, see Configuring JBoss EAP as a Front-end Load Balancer in the JBoss EAP Configuration Guide.

The remainder of this section describes how clustering changes might impact the migration of your applications to JBoss EAP 7.

5.18.2. Alterações nas Web Session Clustering

O JBoss EAP 7 introduz uma nova implementação em web session clustering. Ela substitui a implementação anterior, que era acoplada rigidamente ao código-fonte do subsistema JBoss Web herdado.

A nova implementação Web Session Clustering impacta em como o aplicativo é configurado no arquivo descritor XML do aplicativo web proprietário jboss-web.xml do JBoss. Segue os únicos elementos de configuração de clustering que permaneceram neste arquivo.

<jboss-web>
  ...
  <max-active-sessions>...</max-active-sessions>
  ...
  <replication-config>
    <replication-granularity>...</replication-granularity>
    <cache-name>...</cache-name>
  </replication-config>
  ...
</jboss-web>

A tabela seguinte descreve como conseguir um comportamento similar para elementos no arquivojboss-web.xml que são obsoletos agora.

Elemento de configuração Descrição da alteração

<max-active-sessions/>

Anteriormente, a criação de uma sessão falhava se ela tivesse causado com que o número de sessões ativas excedesse o valor especificado por <max-active-sessions/>.

Na nova implementação, <max-active-sessions/> é utilizada para habilitar passivação de sessão. Se a criação de sessão for resultar em um número de sessões ativas que excede o <max-active-sessions/>, então a sessão mais antiga conhecida ao gerenciador de sessão irá passivar para dar lugar à nova sessão.

<passivation-config/>

Este elemento de configuração e seus subelementos não são mais utilizados em JBoss EAP 7.

<use-session-passivation/>

Anteriormente, a passivação era ativada utilizando este atributo.

Na nova implementação, a passivação é ativada ao especificar um valor não-negativo para <max-active-sessions/>.

<passivation-min-idle-time/>

Anteriormente, as sessões precisavam estar ativas por um período mínimo de tempo antes de tornarem-se candidatas à passivação. Isto poderia causar uma falha na criação de sessão, mesmo que a passivação estivesse habilitada.

A nova implementação não suporta esta lógica e assim evita esta vulnerabilidade de recusa de serviço (Denial of Service - DoS) .

<passivation-max-idle-time/>

Anteriormente, uma sessão tornaria-se passiva após estar inativa por um período especifico de tempo.

A nova implementação suporta somente passivação lazy. Não suporta passivação eager. As sessões são somente passivadas quando necessário para estar em conformidade com <max-active-sessions/>.

<replication-config/>

A nova implementação torna preterido um certo número de subelementos.

<replication-trigger/>

Previously, this element was used to determine when session replication was triggered. The new implementation replaces this configuration option with a single, robust strategy. For more information, see Immutable Session Attributes in the JBoss EAP Development Guide.

<use-jk/>

Anteriormente, a instance-id do nó gerenciando uma determinada solicitação era anexada a jsessionid para uso dos balanceadores de carga, como mod_jk, mod_proxy_balancer, mod_cluster, dependendo do valor especificado para <use-jk/>.

Na nova implementação, a instance-id, se for definida , é sempre anexada ao jsessionid.

<max-unreplicated-interval/>

Anteriormente, esta opção de configuração era destinada a ser uma otimização para evitar a replicação de um carimbo de data/hora de sessão se não houvesse alteração de atributo de sessão. Isto parece bom, mas na prática não evita quaisquer RPCs, já que acesso à sessão necessita transação de cache RPCs independente de qualquer alteração de atributo de sessão.

Na nova implementação, o carimbo de data/hora de uma sessão é replicado a cada solicitação. Isto previne metadados de sessões obsoletas após um failover.

<snapshot-mode/>

Anteriormente, podia-se configurar <snapshot-mode/> como INSTANT ou INTERVAL. A replicação assíncrona de Infinispan torna esta opção de configuração obsoleta.

<snapshot-interval/>

Isto era relevante somente para <snapshot-mode>INTERVAL</snapshot-mode>. Desde que <snapshot-mode/> é obsoleta, agora esta opção também é obsoleta.

<session-notification-policy/>

Anteriormente, o valor especificado por este atributo definia uma política de acionamento de eventos de sessões.

Na nova implementação este comportamento é acionado na especificação e não configurável.

Esta nova implementação também suporta armazenamentos de cache de gravação, bem como armazenamentos de cache somente de passivação. Normalmente, armazenamentos de cache de gravação é usado em conjunto com um cache de invalidação. A implementação de cluster de sessões web no JBoss EAP 6 não funcionou corretamente quando usada com um cache de invalidação.

5.18.3. Alterações em Stateful Session EJB Clustering

No JBoss EAP 6, era exigido que você habilitasse o comportamento do clustering para stateful session beans (SFSBs) em uma das seguintes maneiras.

  • Você podia adicionar a anotação org.jboss.ejb3.annotation.Clustered à sessão bean.

    @Stateful
    @Clustered
    public class MyBean implements MySessionInt {
    
       public void myMethod() {
          //
       }
    }
  • Você podia adicionar o elemento <clustered> ao arquivo jboss-ejb3.xml.

    <c:clustering>
      <ejb-name>DDBasedClusteredSFSB</ejb-name>
      <c:clustered>true</c:clustered>
    </c:clustering>

O JBoss EAP 7 não exige mais que você habilite o comportamento do clustering. Por padrão, se o servidor for iniciado utilizando um perfil HA, o estado de SFSBs será replicado automaticamente.

Você pode desabilitar este comportamento padrão com uma das seguintes maneiras.

  • Você pode desabilitar o comportamento padrão para um único stateful session bean ao utilizar @Stateful(passivationCapable=false), que é novo à especificação EJB 3.2.
  • Você pode desabilitar este comportamento globalmente na configuração do subsistema ejb3 na configuração do servidor.
Nota

Se a anotação @Clustered não for removida do aplicativo, ela será simplesmente ignorada e não afetará a implementação do aplicativo.

5.18.4. Alterações nos serviços de clustering

No JBoss EAP 6, as APIs para serviços de clustering estavam em módulos privados e não eram suportadas.

O JBoss EAP 7 introduz uma API de serviço de clustering público para ser utilizada pelos aplicativos. Os novos serviços são projetados para serem leves, facilmente injetáveis e não necessitar de dependências externas.

  • A nova interface org.wildfly.clustering.group.Group fornece acesso ao status atual do cluster e permite escutar alterações de adesão ao cluster.
  • A nova interface org.wildfly.clustering.dispatcher.CommandDispatcher permite executar código no cluster, em todos os nós ou em determinados subgrupos.

Estes serviços substituem APIs similares que estavam disponíveis em versões prévias, isto é, HAPartition do JBoss EAP 5 e GroupCommunicationService, GroupMembershipNotifier e GroupRpcDispatcher do JBoss EAP 6.

For more information, see Public API for Clustering Services in the JBoss EAP Development Guide.

5.18.5. Migrar Clustering HA Singleton

No JBoss EAP 6, não havia API pública disponível para o serviço global de cluster HA singleton. Se você utilizava as classes privadas org.jboss.as.clustering.singleton.*, você deve alterar seu código para utilizar os novos pacotes públicos org.wildfly.clustering.singleton.* quando você migar seu aplicativo para JBoss EAP 7.

For more information about how to implement an HA singleton, see HA Singleton Service in the Development Guide for JBoss EAP.