Capítulo 5. Alterações na migração dos aplicativos [Esta é uma tradução automática]

A API Java para RPC (JAX-RPC) baseada em XML 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. Os aplicativos que usam JAX-RPC devem ser migrados para uso JAX-WS, que é a atual estrutura de serviços da Web padrão do Java EE.

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

Nas versões anteriores do JBoss EAP, você poderia personalizar a integração do JBossWS e do Apache CXF incluindo uma jbossws-cxf.xml arquivo de configuração com o arquivo de implantação do nó de extremidade. Um caso de uso para isso era configurar cadeias de interceptor para terminais de cliente e servidor de serviço da Web no barramento Apache CXF. Essa integração exigiu que o Spring fosse implantado no servidor do JBoss EAP.

A integração Spring não é mais suportada no JBoss EAP 7. Qualquer aplicativo que contenha jbossws-cxf.xml O arquivo de configuração do descritor deve ser modificado para substituir a configuração personalizada definida nesse arquivo. Embora ainda seja possível acessar diretamente a API do Apache CXF, esteja 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).

Migrar interceptores de mensagem [Esta é uma tradução automática]

O descritor JBossWS fornece novas opções de configuração que permitem declarar os interceptores sem modificar o código do terminal do cliente. Em vez disso, você declara interceptores dentro de configurações predefinidas de cliente e nó de extremidade especificando uma lista de nomes de classe de interceptor para o cxf.interceptors.in e cxf.interceptors.out propriedades.

O seguinte é um exemplo de um jaxws-endpoint-config.xml arquivo que declara interceptores usando essas 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 de configurações predefinidas de cliente e terminal, especificando uma lista de nomes de classes de cxf.features propriedade.

O seguinte é um exemplo de um jaxws-endpoint-config.xml arquivo que declara um recurso usando essa 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

No Apache CXF, a configuração de transporte HTTP é obtida especificando org.apache.cxf.transport.http.HTTPConduit opções. A integração do JBossWS permite que as condutas sejam modificadas programaticamente usando a API Apache CXF da seguinte forma.

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ê também pode controlar e substituir o Apache CXF HTTPConduit valores padrão, definindo as propriedades do sistema.

o cxf-api e cxf-rt-core JARs foram fundidos em um cxf-core JAR. Como conseqüência, org.apache.cxf módulo no JBoss EAP agora contém o cxf-core JAR e expõe mais classes do que na versão anterior.

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.

O JBoss EAP 7 vem com o org.bouncycastle módulo e JBossWS agora é capaz de confiar em seu carregador de classe para obter e usar o provedor de segurança BouncyCastle. Portanto, não é mais necessário instalar estaticamente o BouncyCastle na JVM atual. Para aplicativos em execução fora do contêiner, o provedor de segurança pode ser disponibilizado para o JBossWS adicionando uma biblioteca BouncyCastle ao caminho da classe.

Você pode desativar esse comportamento definindo org.jboss.ws.cxf.noLocalBC valor da propriedade para true no jaxws-endpoint-config.xml arquivo descritor de implementação para o servidor ou o jaxws-client-config.xml arquivo descritor para 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.

A estratégia de seleção de barramento padrão para clientes em execução no container foi alterada de THREAD_BUS para TCCL_BUS. Para clientes que estão ficando sem contêiner, a estratégia padrão ainda é THREAD_BUS. Você pode restaurar o comportamento para o release anterior usando um dos seguintes métodos.

Os contêineres devem usar os construtores de estilo JAX-WS 2.2, que incluem o WebServiceFeature class como um argumento no construtor, para construir clientes que são injetados em referências de serviço da web. O JBoss EAP 6.4, que acompanha o JBossWS 4, oculta esse requisito. O JBoss EAP 7 é fornecido com o JBossWS 5, que não oculta mais esse requisito. Isso significa que as classes de serviço fornecidas pelo usuário devem implementar o JAX-WS 2.2 ou posterior, atualizando o código existente para usar o javax.xml.ws.Service construtor que inclui um ou mais WebServiceFeature argumentos.

protected Service(URL wsdlDocumentLocation,
       QName serviceName,
       WebServiceFeature... features)

Em versões anteriores, você poderia desabilitar a verificação de nome de host de URL HTTPS em relação ao Nome Comum (CN) de um serviço fornecido em seu certificado, definindo a propriedade do sistema org.jboss.security.ignoreHttpsHost para true. Este nome de propriedade do sistema foi substituído por cxf.tls-client.disableCNCheck.

Como consequência da ativação de injeções em manipuladores de clientes de serviço e de terminal, não é mais possível carregar automaticamente classes do manipulador org.jboss.as.webservices.server.integration Módulo JBoss. Se seu aplicativo depender de uma determinada configuração predefinida, talvez seja necessário definir explicitamente novas dependências do módulo para sua implementação. Para mais informações, veja Migrar Dependências de Módulo Explícito

o Mecanismo de substituição de padrões endossados ​​por Java foi preterido no JDK 1.8_40 com a intenção de removê-lo no JDK 9. Esse mecanismo permitiu que os desenvolvedores disponibilizassem as bibliotecas para todos os aplicativos implementados, colocando 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.

Nas versões anteriores do JBoss EAP, você poderia configurar o jboss-webservices.xml arquivo descritor de implementação para implantações de serviços da Web EJB no META-INF/ diretório de arquivos JAR ou no WEB-INF/ diretório para implementações de serviço da web POJO e terminais de serviço da Web EJB agrupados em arquivos WAR.

No JBoss EAP 7, agora você pode configurar o jboss-webservices.xml arquivo descritor de implementação no META-INF/ diretório de um arquivo EAR. Se um jboss-webservices.xml arquivo é encontrado no arquivo EAR e no arquivo JAR ou WAR, os dados de configuração no arquivo jboss-webservices.xml O arquivo para o JAR ou WAR substitui os dados correspondentes no arquivo do descritor EAR.

Os arquivos proprietários do descritor de implementação de recursos do HornetQ JMS identificados pelo padrão de nomenclatura -jms.xml não funciona mais no JBoss EAP 7. A seguir, um exemplo de um arquivo 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 -jms.xml Descritores de implementação JMS em seu aplicativo no release anterior, você pode converter seu aplicativo para usar o descritor de implementação padrão do Java EE 7, conforme especificado na seção EE.5.18 do Especificação Java EE 7 ou você pode atualizar o descritor de implantação para usar o messaging-activemq-deployment esquema em vez disso.

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

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 obter informações sobre alterações de configuração do servidor relacionadas a mensagens, consulte Alterações na configuração do servidor de mensagens.

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

O conector e a porta remotos padrão foram alterados no JBoss EAP 7. Para obter detalhes sobre essa alteração, consulte Atualizar o conector e porta de URL remoto.

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

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

O JBoss EAP 6 incluiu o org.hornetq módulo, o que lhe permitiu usar o API do HornetQ no código-fonte da sua aplicação.

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

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

Classes de corpo de mensagem e interceptores

JSR 311: JAX-RS: A API Java ™ para serviços da Web RESTful não incluiu um framework interceptador, então o RESTEasy 2 forneceu um. JSR 339: JAX-RS 2.0: A API Java para serviços da Web RESTful introduziu uma estrutura oficial de interceptador e filtro, de modo que a estrutura do interceptador incluída no RESTEasy 2 está obsoleta e é substituída pela instalação do interceptor compatível com JAX-RS 2.0 no RESTEasy 3.x. As interfaces relevantes são definidas no javax.ws.rs.ext pacote do jaxrs-api módulo.

Para obter mais informações sobre interceptores, consulte Interceptores RESTEasy dentro Desenvolvendo Aplicativos de Serviços da Web para o JBoss EAP.

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

API Cliente

A estrutura do cliente RESTEasy em resteasy-jaxrs foi substituído pelo padrão JAX-RS 2.0 resteasy-client módulo. Como resultado, algumas classes e métodos da API do cliente RESTEasy foram descontinuados.

StringConverter

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

Métodos de adição de ResteasyProviderFactory

A maioria dos org.jboss.resteasy.spi.ResteasyProviderFactory add() métodos foram removidos ou protegidos no RESTEasy 3.0. Por exemplo, o addBuiltInMessageBodyReader() e addBuiltInMessageBodyWriter() métodos foram removidos e os addMessageBodyReader() e addMessageBodyWriter() métodos foram protegidos.

Você deve agora usar o registerProvider() e registerProviderInstance() métodos.

Classes suplementares removidas do RESTEasy 3

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

SignedInput e SignedOuput

Alterações WS-Security

Os filtros de segurança para @RolesAllowed, @PermitAll, e @DenyAll agora retorne "403 Proibido" em vez de "401 Não Autorizado".

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

Como a especificação JAX-RS 2.0 adiciona suporte HTTP assíncrono usando o @Suspended anotação e o AsynResponse interface, a API proprietária do RESTEasy para HTTP assíncrono foi preterida e pode ser removida em uma versão futura do RESTEasy. Os módulos assíncronos Tomcat e JBoss Web assíncronos também foram removidos da instalação do servidor. Se você não estiver usando o contêiner Servlet 3.0 ou superior, o processamento do lado do servidor HTTP assíncrono será simulado e executado de forma síncrona no mesmo encadeamento de solicitação.

Cache do lado do servidor

A configuração do cache do lado do servidor foi alterada. por favor veja o Documentação RESTEasy Para maiores informações.

Alterações do provedor Jackson [Esta é uma tradução automática]

Nas versões anteriores do JBoss EAP, a configuração do provedor RESTEasy YAML era ativada por padrão. Isso mudou no JBoss EAP 7. O provedor YAML agora está desabilitado por padrão. Seu uso não é suportado devido a um problema de segurança no SnakeYAML biblioteca usada pelo RESTEasy para unmarshalling e deve ser ativada explicitamente no aplicativo. Para obter informações sobre como habilitar o provedor YAML em seu aplicativo e adicionar as dependências do Maven, consulte Provedor YAML dentro Desenvolvendo Aplicativos de Serviços da Web para o JBoss EAP.

Charset padrão UTF-8 no cabeçalho Content-Type

No JBoss EAP 7.1, o resteasy.add.charset parâmetro está definido como true por padrão. Você pode definir o resteasy.add.charset parâmetro para false se você não quiser que o RESTEasy adicione charset=UTF-8 para o cabeçalho de tipo de conteúdo retornado quando o método de recurso retorna um text/* ou application/xml* tipo de mídia sem um conjunto de caracteres explícito.

Para obter mais informações sobre tipos de mídia de texto e conjuntos de caracteres, consulte Tipos de mídia de texto e conjuntos de caracteres dentro Desenvolvendo Aplicativos de Serviços da Web para o JBoss EAP.

SerializableProvider

A desserialização de objetos Java de fontes não confiáveis ​​não é segura. Por esta razão, no JBoss EAP 7, o org.jboss.resteasy.plugins.providers.SerializableProvider A classe está desabilitada por padrão e não é recomendável usar esse provedor.

Solicitações correspondentes aos métodos de recursos

No RESTEasy 3, melhorias e correções foram feitas na implementação de regras de correspondência, conforme definido na especificação JAX-RS 2.0. Em particular, foi feita uma alteração na forma como um URI ambíguo em um método de sub-recurso e um localizador de sub-recurso é tratado.

No RESTEasy 2, era possível que um localizador de sub-recursos fosse executado com sucesso mesmo quando havia outro sub-recurso com o mesmo URI. Esse comportamento estava incorreto de acordo com a especificação.

No RESTEasy 3, quando houver um URI ambíguo para um sub-recurso e um localizador de sub-recurso, chamar o sub-recurso será bem-sucedido; no entanto, chamar o localizador de sub-recurso resultará em um status HTTP 405 Method Not Allowed erro.

O exemplo a seguir contém um erro ambíguo @Path anotação em um método de sub-recurso e um localizador de sub-recurso. Observe que o URI para ambos os endpoints, anotherResource e anotherResourceLocator, é o mesmo. A diferença entre os dois pontos finais é que o anotherResource método está associado com o verbo REST, POST. o anotherResourceLocator O método não está associado a nenhum verbo REST. De acordo com a especificação, o terminal com o verbo REST, neste caso, o anotherResource método, sempre será selecionado.

@Path("myResource")
public class ExampleSubResources {
    @POST
    @Path("items")
    @Produces("text/plain")
    public Response anotherResource(String text) {
        return Response.ok("ok").build();
    }

    @Path("items")
    @Produces("text/plain")
    public SubResource anotherResourceLocator() {
        return new SubResource();
    }
}

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.

InjectorFactory e Registro

o InjectorFactory e Registry SPIs mudaram. Isso não deve ser um problema se você usar o RESTEasy conforme documentado e suportado.

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

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

Para mudar seu aplicativo para usar o provedor padrão que foi incluído na versão anterior do JBoss EAP, veja Mudando o provedor Jackson padrão dentro Desenvolvendo Aplicativos de Serviços da Web para o JBoss EAP.

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.

O provedor JSON do RESTEasy Jettison está obsoleto no JBoss EAP 7 e não é mais adicionado às implementações por padrão. Você é encorajado a mudar para o fornecedor recomendado do RESTEasy Jackson. Se preferir continuar a usar o provedor Jettison, você deve definir uma dependência explícita para ele no jboss-deployment-descriptor.xml arquivo conforme demonstrado no exemplo a seguir.

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

Para obter mais informações sobre como definir dependências explícitas, consulte Adicionar uma dependência de módulo explícita a uma implantação no JBoss EAP Guia de desenvolvimento.

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.

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.

As aplicações escritas com o Hibernate ORM 4.x ainda podem usar o Hibernate ORM 4.x. Você deve definir um módulo JBoss personalizado para os JARs ORM 4.x do Hibernate e excluir as classes Hibernate ORM 5 do seu aplicativo. No entanto, é altamente recomendável que você reescreva o código do aplicativo para usar o Hibernate ORM 5. Para obter informações sobre como migrar para o Hibernate ORM 5, consulte Migrando para o Hibernate ORM 5.

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

Classes preteridas de RESTEasy [Esta é uma tradução automática]

As seguintes classes reprovadas foram removidas do Hibernate ORM 5:

Outras alterações às classes e pacotes

Type Handling

Alterações do subsistema de transações [Esta é uma tradução automática]

Alterações no Hibernate Search [Esta é uma tradução automática]

Enquanto o JBoss EAP 7.0 incluía o Hibernate ORM 5.0, o JBoss EAP 7.1 agora inclui o Hibernate ORM 5.1. Esta seção destaca as diferenças e as mudanças necessárias ao migrar do Hibernate ORM versão 5.0 para a versão 5.1.

Hibernate ORM 3.0 [Esta é uma tradução automática]

Esta versão inclui muitas melhorias de desempenho e correções de bugs, que são detalhadas em Recursos do Hibernate ORM 5.1 no JBoss EAP Notas de versão 7.1.0. Para informações adicionais sobre as mudanças implementadas entre o Hibernate ORM 5.0 eo Hibernate ORM 5.1, veja o Hibernate ORM 5.1 Guia de Migração.

Mudanças no gerenciamento de JMX [Esta é uma tradução automática]

Mudanças no Cliente EJB no JBoss EAP 7 [Esta é uma tradução automática]

As mudanças de ferramentas de gerenciamento de esquema no Hibernate ORM 5.1 são principalmente focadas nas seguintes áreas:

As alterações de ferramentas de gerenciamento de esquema devem ser apenas uma preocupação de migração para aplicativos que usam diretamente qualquer uma das seguintes classes:

Mudanças de Configuração de Mensagens no JBoss EAP 7.1 [Esta é uma tradução automática]

O Hibernate ORM 5.1.10, incluído no JBoss EAP 7.1, introduziu uma nova estratégia para recuperar tabelas de banco de dados que melhoram SchemaMigrator e SchemaValidator desempenho. Esta estratégia executa uma única java.sql.DatabaseMetaData#getTables(String, String, String, String[]) ligue para determinar se cada javax.persistence.Entity tem uma tabela de banco de dados mapeada. Esta é a estratégia padrão, e usa o hibernate.hbm2ddl.jdbc_metadata_extraction_strategy=grouped configuração de propriedade. Essa estratégia pode exigir hibernate.default_schema e / ou hibernate.default_catalog ser provido.

Para usar a estratégia antiga, que executa uma java.sql.DatabaseMetaData#getTables(String, String, String, String[]) chamar para each javax.persistence.Entity, use o hibernate.hbm2ddl.jdbc_metadata_extraction_strategy=individually configuração de propriedade.

No JBoss EAP 7.0, a verificação de erro de contexto de persistência não sincronizada não era tão rigorosa quanto deveria nas áreas a seguir.

Além do que, além do mais, PersistenceProperty sugestões no @PersistenceContext foram erroneamente ignorados no JBoss EAP 7.0.

Esses problemas foram abordados e corrigidos no JBoss EAP 7.1. Como essas atualizações podem resultar em uma mudança indesejada no comportamento do aplicativo, duas novas propriedades de unidade de persistência foram introduzidas no JBoss EAP 7.1 para fornecer compatibilidade com versões anteriores e preservar o comportamento anterior.

O conector e a porta remotos padrão foram alterados no JBoss EAP 7. Para obter detalhes sobre essa alteração, consulte Atualizar o conector e porta de URL remoto.

Se você usou o migrate operação para migrar a configuração do servidor, as configurações antigas são preservadas e você não precisa fazer as alterações detalhadas abaixo. No entanto, se você executar com a nova configuração padrão do JBoss EAP 7, deverá fazer as seguintes alterações.

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

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

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.wildfly.naming.client.WildFlyInitialContextFactory
java.naming.provider.url=http-remoting://localhost:8080

Enquanto o JBoss EAP 7.0 é fornecido com o JBoss EJB Client 2.1.4, o JBoss EAP 7.1 é fornecido com o JBoss EJB Client 4.0.x, que inclui várias mudanças na API.

Se você criou uma válvula autenticadora personalizada que AuthenticatorBase no JBoss EAP 6.4, você deve substituí-lo manualmente por uma implementação de autenticação HTTP personalizada no JBoss EAP 7.1. O mecanismo de autenticação HTTP é criado no elytron subsistema e, em seguida, registrado com o undertow subsistema. Para obter informações sobre como implementar um mecanismo de autenticação HTTP personalizado, consulte Implementando um Mecanismo HTTP Customizado no Guia de desenvolvimento para o JBoss EAP.

Para obter informações sobre as alterações necessárias para o SSO com configuração do SAML v2, consulte Mudanças das versões anteriores do JBoss EAP dentro Como configurar o SSO com o SAML v2 para o JBoss EAP.

Para obter informações sobre as diferenças na configuração de SSO com o Kerberos, consulte Diferenças de Configurando Versões Anteriores do JBoss EAP dentro Como configurar o SSO com o Kerberos para o JBoss EAP.

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.

O restante desta seção descreve como as mudanças de cluster podem impactar a migração de seus aplicativos para o JBoss EAP 7.

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 de clustering de sessões da Web afeta o modo como o aplicativo é configurado no jboss-web.xml Arquivo de descritor XML do aplicativo da web proprietário do JBoss EAP. A seguir estão os únicos elementos de configuração de cluster que permanecem nesse 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 a seguir descreve como obter um comportamento semelhante para elementos no jboss-web.xml arquivo que agora está obsoleto.

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.

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

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.

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.

Esses serviços substituem APIs similares que estavam disponíveis em releases anteriores, HAPartition do JBoss EAP 5 e GroupCommunicationService, GroupMembershipNotifier, e GroupRpcDispatcher no JBoss EAP 6.

Para mais informações, veja API pública para serviços de cluster no JBoss EAP Guia de desenvolvimento.

No JBoss EAP 6, não havia nenhuma API pública disponível para o serviço de singleton de HA em todo o cluster. Se você usou o privado org.jboss.as.clustering.singleton.* classes, você deve alterar seu código para usar o novo org.wildfly.clustering.singleton.* pacotes quando você migra seu aplicativo para o JBoss EAP 7.

Para obter mais informações sobre serviços singleton de HA, consulte Serviço HA Singleton no Guia de desenvolvimento para o JBoss EAP. Para obter informações sobre implantações de singleton de alta disponibilidade, consulte Implantações de HA Singleton no Guia de desenvolvimento para o JBoss EAP.