Guia de Migração [Esta é uma tradução automática]

Os registros de mensagens são prefixados com o código do projeto para o subsistema que relata a mensagem. Os prefixos para todos os registros de mensagens foram alterados no JBoss EAP 7.

Para uma lista completa dos novos prefixos de código de projeto de mensagem de log usados ​​no JBoss EAP 7, veja Códigos de Projeto Utilizados no JBoss EAP no JBoss EAP Guia de desenvolvimento.

O criador de logs raiz do JBoss EAP 7.0 incluiu um manipulador de logs do console para todos os perfis de servidor de domínio e para todos os perfis independentes padrão, exceto o standalone-full-ha perfil. O criador de logs raiz do JBoss EAP 7.1 não inclui mais um manipulador de logs do console para os perfis de domínio gerenciados. O controlador host e o controlador de processo registram no console por padrão. Para obter a mesma funcionalidade que foi fornecida no JBoss EAP 7.0, veja Configurar um manipulador de log do console no Guia de configuração para o JBoss EAP.

Undertow substitui o JBoss Web como o servidor web no JBoss EAP 7. Isso significa que o legado web A configuração do subsistema deve ser migrada para o novo JBoss EAP 7 undertow configuração do subsistema.

Você pode usar o CLI de gerenciamento migrate operação para migrar o web subsistema para undertow no arquivo de configuração do servidor. No entanto, esteja ciente de que esta operação não é capaz de migrar todas as configurações do subsistema Web do JBoss. Se você vir entradas de "aviso de migração", deverá executar comandos CLI de gerenciamento adicionais para migrar essas configurações para Undertow. Para mais informações sobre o CLI de gerenciamento migrate operação, consulte Operação de Migração do CLI de Gerenciamento.

O seguinte é um exemplo do padrão web configuração do subsistema no JBoss EAP 6.

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
    <virtual-server name="default-host" enable-welcome-root="true">
        <alias name="localhost"/>
        <alias name="example.com"/>
    </virtual-server>
</subsystem>

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
    <virtual-server name="default-host" enable-welcome-root="true">
        <alias name="localhost"/>
        <alias name="example.com"/>
    </virtual-server>
</subsystem>

O seguinte é um exemplo do padrão undertow configuração do subsistema no JBoss EAP 7.

<subsystem xmlns="urn:jboss:domain:undertow:4.0">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <filter-ref name="server-header"/>
            <filter-ref name="x-powered-by-header"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
        <websockets/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <filters>
        <response-header name="server-header" header-name="Server" header-value="JBoss-EAP/7"/>
        <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
    </filters>
</subsystem>

<subsystem xmlns="urn:jboss:domain:undertow:4.0">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <filter-ref name="server-header"/>
            <filter-ref name="x-powered-by-header"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
        <websockets/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <filters>
        <response-header name="server-header" header-name="Server" header-value="JBoss-EAP/7"/>
        <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
    </filters>
</subsystem>

O CLI de gerenciamento migrate operação não é capaz de migrar automaticamente as condições de reescrita. Eles são relatados como "avisos de migração" e você deve migrá-los manualmente. Você pode criar a configuração equivalente no JBoss EAP 7 usando Atributos e manipuladores de predicados inferiores.

O seguinte é um exemplo de um web configuração do subsistema no JBoss EAP 6 que inclui rewrite configuração.

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default" native="false">
    <virtual-server name="default" enable-welcome-root="true">
        <alias name="localhost"/>
        <rewrite name="test" pattern="(.*)/toberewritten/(.*)" substitution="$1/rewritten/$2" flags="NC"/>
        <rewrite name="test2" pattern="(.*)" substitution="-" flags="F">
            <condition name="get" test="%{REQUEST_METHOD}" pattern="GET"/>
            <condition name="andCond" test="%{REQUEST_URI}" pattern=".*index.html" flags="NC"/>
        </rewrite>
    </virtual-server>
</subsystem>

<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default" native="false">
    <virtual-server name="default" enable-welcome-root="true">
        <alias name="localhost"/>
        <rewrite name="test" pattern="(.*)/toberewritten/(.*)" substitution="$1/rewritten/$2" flags="NC"/>
        <rewrite name="test2" pattern="(.*)" substitution="-" flags="F">
            <condition name="get" test="%{REQUEST_METHOD}" pattern="GET"/>
            <condition name="andCond" test="%{REQUEST_URI}" pattern=".*index.html" flags="NC"/>
        </rewrite>
    </virtual-server>
</subsystem>

Segue o Operação de Migração do CLI de Gerenciamento instruções para iniciar seu servidor e a CLI de gerenciamento, depois migrar web arquivo de configuração do subsistema usando o seguinte comando.

/subsystem=web:migrate

/subsystem=web:migrate

Os seguintes "avisos de migração" são relatados quando você executa o migrate operação na configuração acima.

/subsystem=web:migrate
{
    "outcome" => "success",
    "result" => {"migration-warnings" => [
        "WFLYWEB0002: Could not migrate resource {
    \"pattern\" => \"(.*)\",
    \"substitution\" => \"-\",
    \"flags\" => \"F\",
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\")
    ]
}",
        "WFLYWEB0002: Could not migrate resource {
    \"test\" => \"%{REQUEST_METHOD}\",
    \"pattern\" => \"GET\",
    \"flags\" => undefined,
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\"),
        (\"condition\" => \"get\")
    ]
}",
        "WFLYWEB0002: Could not migrate resource {
    \"test\" => \"%{REQUEST_URI}\",
    \"pattern\" => \".*index.html\",
    \"flags\" => \"NC\",
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\"),
        (\"condition\" => \"andCond\")
    ]
}"
    ]}
}

/subsystem=web:migrate
{
    "outcome" => "success",
    "result" => {"migration-warnings" => [
        "WFLYWEB0002: Could not migrate resource {
    \"pattern\" => \"(.*)\",
    \"substitution\" => \"-\",
    \"flags\" => \"F\",
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\")
    ]
}",
        "WFLYWEB0002: Could not migrate resource {
    \"test\" => \"%{REQUEST_METHOD}\",
    \"pattern\" => \"GET\",
    \"flags\" => undefined,
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\"),
        (\"condition\" => \"get\")
    ]
}",
        "WFLYWEB0002: Could not migrate resource {
    \"test\" => \"%{REQUEST_URI}\",
    \"pattern\" => \".*index.html\",
    \"flags\" => \"NC\",
    \"operation\" => \"add\",
    \"address\" => [
        (\"subsystem\" => \"web\"),
        (\"virtual-server\" => \"default-host\"),
        (\"rewrite\" => \"test2\"),
        (\"condition\" => \"andCond\")
    ]
}"
    ]}
}

Revise o arquivo de configuração do servidor e você verá a seguinte configuração para o undertow subsistema.

<subsystem xmlns="urn:jboss:domain:undertow:4.0">
     <buffer-cache name="default"/>
     <server name="default-server">
         <http-listener name="http" socket-binding="http"/>
         <host name="default-host" alias="localhost, example.com">
             <location name="/" handler="welcome-content"/>
         </host>
     </server>
     <servlet-container name="default">
         <jsp-config/>
     </servlet-container>
     <handlers>
         <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
     </handlers>
 </subsystem>

<subsystem xmlns="urn:jboss:domain:undertow:4.0">
     <buffer-cache name="default"/>
     <server name="default-server">
         <http-listener name="http" socket-binding="http"/>
         <host name="default-host" alias="localhost, example.com">
             <location name="/" handler="welcome-content"/>
         </host>
     </server>
     <servlet-container name="default">
         <jsp-config/>
     </servlet-container>
     <handlers>
         <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
     </handlers>
 </subsystem>

Use a CLI de gerenciamento para criar o filtro para substituir a configuração de reconfiguração no undertow subsistema. Você deve ver "{" resultado "⇒" sucesso "}" para cada comando.

# Create the filters
/subsystem=undertow/configuration=filter/expression-filter="test1":add(expression="path('(.*)/toberewritten/(.*)') -> rewrite('$1/rewritten/$2')")
/subsystem=undertow/configuration=filter/expression-filter="test2":add(expression="method('GET') and path('.*index.html') -> response-code(403)")

# Add the filters to the default server
/subsystem=undertow/server=default-server/host=default-host/filter-ref="test1":add
/subsystem=undertow/server=default-server/host=default-host/filter-ref="test2":add

# Create the filters
/subsystem=undertow/configuration=filter/expression-filter="test1":add(expression="path('(.*)/toberewritten/(.*)') -> rewrite('$1/rewritten/$2')")
/subsystem=undertow/configuration=filter/expression-filter="test2":add(expression="method('GET') and path('.*index.html') -> response-code(403)")

# Add the filters to the default server
/subsystem=undertow/server=default-server/host=default-host/filter-ref="test1":add
/subsystem=undertow/server=default-server/host=default-host/filter-ref="test2":add

Revise o arquivo de configuração do servidor atualizado. O subsistema Web JBoss está agora completamente migrado e configurado no undertow subsistema.

<subsystem xmlns="urn:jboss:domain:undertow:4.0">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="http" socket-binding="http"/>
        <host name="default-host" alias="localhost, example.com">
            <location name="/" handler="welcome-content"/>
            <filter-ref name="test1"/>
            <filter-ref name="test2"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <filters>
        <expression-filter name="test1" expression="path('(.*)/toberewritten/(.*)') -> rewrite('$1/rewritten/$2')"/>
        <expression-filter name="test2" expression="method('GET') and path('.*index.html') -> response-code(403)"/>
    </filters>
</subsystem>

<subsystem xmlns="urn:jboss:domain:undertow:4.0">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="http" socket-binding="http"/>
        <host name="default-host" alias="localhost, example.com">
            <location name="/" handler="welcome-content"/>
            <filter-ref name="test1"/>
            <filter-ref name="test2"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <filters>
        <expression-filter name="test1" expression="path('(.*)/toberewritten/(.*)') -> rewrite('$1/rewritten/$2')"/>
        <expression-filter name="test2" expression="method('GET') and path('.*index.html') -> response-code(403)"/>
    </filters>
</subsystem>

Para obter mais informações sobre como configurar filtros e manipuladores usando a CLI de gerenciamento, consulte Configurando o Servidor da Web no JBoss EAP 7 Guia de configuração.

Na versão anterior do JBoss EAP, as propriedades do sistema poderiam ser usadas para modificar o comportamento padrão do JBoss. Para obter informações sobre como configurar o mesmo comportamento no Undertow, consulte Referência de Migração de Propriedades do Sistema JBoss Web

Quando você migra do JBoss EAP 6.4 para o JBoss EAP 7.1, você pode achar que os logs de acesso não gravam mais os valores esperados "Referer" e "User-agent". Isto é porque o JBoss Web, que foi incluído no JBoss EAP 6.4, usou um padrão de %{headername}i no access-log para registrar um cabeçalho de entrada.

<access-log pattern="%h %l %u %t &quot;%T sec&quot; &quot;%r&quot; %s %b &quot;%{Referer}i&quot; &quot;%{User-agent}i&quot;"/>

<access-log pattern="%h %l %u %t &quot;%T sec&quot; &quot;%r&quot; %s %b &quot;%{Referer}i&quot; &quot;%{User-agent}i&quot;"/>

Com a mudança para usar o Undertow no JBoss EAP 7.1, o padrão para um cabeçalho de entrada foi alterado para %{i,headername}.

<access-log pattern="%h %l %u %t &quot;%T sec&quot; &quot;%r&quot; %s %b &quot;%{i,Referer}&quot; &quot;%{i,User-Agent}&quot;"/>

<access-log pattern="%h %l %u %t &quot;%T sec&quot; &quot;%r&quot; %s %b &quot;%{i,Referer}&quot; &quot;%{i,User-Agent}&quot;"/>

As versões anteriores do JBoss EAP tinham suporte de válvulas. Válvulas são classes personalizadas inseridas na pipeline de processamento de solicitações para um aplicativo antes de filtros servlet para fazer alterações às solicitações ou executar processamento adicional.

Esta seção descreve como migrar válvulas globais. A migração de válvulas personalizadas e autenticadoras é coberta Migrar válvulas de aplicativos personalizados seção deste guia.

Undertow, que substitui JBoss Web no JBoss EAP 7, não suporta válvulas globais; porém, você pode conseguir funcionalidade semelhante utilizando os manipuladores Undertow. Undertow inclui um número de manipuladores integrados que fornecem funcionalidade comum. Também fornece a habilidade de criar manipuladores personalizados, que podem ser utilizados para substituir funcionalidade de válvula personalizada.

Se o seu aplicativo utilizar válvulas, você deve substituí-las com o código de manipulador Undertow adequado para obter a mesma funcionalidade quando você migrar para o JBoss EAP 7.

Para obter mais informações sobre como configurar manipuladores, consulte Configurando manipuladores no JBoss EAP 7 Guia de configuração.

Para obter mais informações sobre como configurar filtros, consulte Configurando Filtros no JBoss EAP 7 Guia de configuração.

Migrar válvulas globais [Esta é uma tradução automática]

A tabela a seguir lista as válvulas que foram fornecidas pelo JBoss Web no release anterior do JBoss EAP e o manipulador integrado Undertow correspondente. As válvulas do JBoss Web estão localizadas no org.apache.catalina.valves pacote.

Você pode usar o CLI de gerenciamento migrate operação para migrar automaticamente válvulas globais que atendam aos seguintes critérios:

Para mais informações sobre o CLI de gerenciamento migrate operação, consulte Operação de Migração do CLI de Gerenciamento.

Procedimento de migração manual JDBCAccessLogValve

o org.apache.catalina.valves.JDBCAccessLogValve válvula é uma exceção à regra e não pode ser migrada automaticamente para io.undertow.server.handlers.JDBCLogHandler. Siga as etapas abaixo para migrar a seguinte válvula de exemplo.

<valve name="jdbc" module="org.jboss.as.web" class-name="org.apache.catalina.valves.JDBCAccessLogValve">
    <param param-name="driverName" param-value="com.mysql.jdbc.Driver" />
    <param param-name="connectionName" param-value="root" />
    <param param-name="connectionPassword" param-value="password" />
    <param param-name="connectionURL" param-value="jdbc:mysql://localhost:3306/wildfly?zeroDateTimeBehavior=convertToNull" />
    <param param-name="format" param-value="combined" />
</valve>

<valve name="jdbc" module="org.jboss.as.web" class-name="org.apache.catalina.valves.JDBCAccessLogValve">
    <param param-name="driverName" param-value="com.mysql.jdbc.Driver" />
    <param param-name="connectionName" param-value="root" />
    <param param-name="connectionPassword" param-value="password" />
    <param param-name="connectionURL" param-value="jdbc:mysql://localhost:3306/wildfly?zeroDateTimeBehavior=convertToNull" />
    <param param-name="format" param-value="combined" />
</valve>

Especificações anteriores para Set-Cookie A sintaxe do cabeçalho de resposta HTTP, por exemplo, RFC2109 e RFC2965, permitia espaço em branco e outros caracteres separadores no valor do cookie quando o valor do cookie era citado. O JBoss Web no JBoss EAP 6.4 estava de acordo com as especificações anteriores e automaticamente citava um valor de cookie quando continha quaisquer caracteres separadores.

o RFC6265 especificação para Set-Cookie A sintaxe do cabeçalho de resposta HTTP indica que os valores de cookie no Set-Cookie O cabeçalho de resposta deve estar em conformidade com as restrições gramaticais específicas. Por exemplo, eles devem ser caracteres US-ASCII, mas não podem incluir CTRLs (controles), espaço em branco, aspas duplas, vírgulas, ponto e vírgula ou caracteres de barra invertida.

No JBoss EAP 7.0, antes do patch cumulativo Red Hat JBoss Enterprise Application Platform 7,0 atualização 08, Undertow não restringe esses caracteres inválidos e não cita cookies que continham os caracteres excluídos. Se você aplicar esse patch cumulativo ou um patch cumulativo mais recente, poderá ativar a validação de cookie compatível com RFC6265 definindo io.undertow.cookie.DEFAULT_ENABLE_RFC6265_COOKIE_VALIDATION propriedade do sistema para true.

No JBoss EAP 7.1, por padrão, Undertow não habilita a validação de cookie compatível com RFC6265. Ele cita cookies que contêm os caracteres excluídos. No JBoss EAP 7.1, você não pode usar o io.undertow.cookie.DEFAULT_ENABLE_RFC6265_COOKIE_VALIDATION propriedade do sistema para ativar a validação de cookie compatível com RFC6265. Em vez disso, você ativa a validação de cookie compatível com RFC6265 para um ouvinte HTTP, HTTPS ou AJP configurando o rfc6265-cookie-validation atributo de ouvinte para true. O valor padrão para este atributo é false. O exemplo a seguir ativa a validação de cookie compatível com RFC6265 para o ouvinte HTTP.

/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=rfc6265-cookie-validation,value=true)

/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=rfc6265-cookie-validation,value=true)

O JBoss EAP 6.4, que incluía o JBoss Web como servidor web, permitia TRACE chamadas de método por padrão.

Undertow, que substitui o JBoss Web como o servidor web no JBoss EAP 7, não permite HTTP TRACE chamadas de método por padrão. Esta configuração é configurada usando o disallowed-methods atributo do http-listener elemento no undertow subsistema. Isso pode ser confirmado pela análise da saída dos seguintes read-resource comando. Observe que o valor para o disallowed-methods atributo é ["TRACE"].

/subsystem=undertow/server=default-server/http-listener=default:read-resource
{
    "outcome" => "success",
    "result" => {
        "allow-encoded-slash" => false,
        "allow-equals-in-cookie-value" => false,
        "always-set-keep-alive" => true,
        "buffer-pipelined-data" => false,
        "buffer-pool" => "default",
        "certificate-forwarding" => false,
        "decode-url" => true,
        "disallowed-methods" => ["TRACE"],
         ...
    }
}

/subsystem=undertow/server=default-server/http-listener=default:read-resource
{
    "outcome" => "success",
    "result" => {
        "allow-encoded-slash" => false,
        "allow-equals-in-cookie-value" => false,
        "always-set-keep-alive" => true,
        "buffer-pipelined-data" => false,
        "buffer-pool" => "default",
        "certificate-forwarding" => false,
        "decode-url" => true,
        "disallowed-methods" => ["TRACE"],
         ...
    }
}

Para ativar o HTTP TRACE chamadas de método no JBoss EAP 7 e posterior, você deve remover a entrada "TRACE" do disallowed-methods lista de atributos executando o seguinte comando.

/subsystem=undertow/server=default-server/http-listener=default:list-remove(name=disallowed-methods,value="TRACE")

/subsystem=undertow/server=default-server/http-listener=default:list-remove(name=disallowed-methods,value="TRACE")

Quando você executa o read-resource comando novamente, você vai notar o TRACE chamada de método não está mais na lista de métodos não permitidos.

/subsystem=undertow/server=default-server/http-listener=default:read-resource
{
    "outcome" => "success",
    "result" => {
        "allow-encoded-slash" => false,
        "allow-equals-in-cookie-value" => false,
        "always-set-keep-alive" => true,
        "buffer-pipelined-data" => false,
        "buffer-pool" => "default",
        "certificate-forwarding" => false,
        "decode-url" => true,
        "disallowed-methods" => [],
         ...
    }
}

/subsystem=undertow/server=default-server/http-listener=default:read-resource
{
    "outcome" => "success",
    "result" => {
        "allow-encoded-slash" => false,
        "allow-equals-in-cookie-value" => false,
        "always-set-keep-alive" => true,
        "buffer-pipelined-data" => false,
        "buffer-pool" => "default",
        "certificate-forwarding" => false,
        "decode-url" => true,
        "disallowed-methods" => [],
         ...
    }
}

Para obter mais informações sobre o comportamento padrão dos métodos HTTP, consulte Comportamento Padrão de Métodos HTTP no JBoss EAP Guia de configuração.

No JBoss EAP 7.0, o contexto raiz de uma aplicação web foi desabilitado por padrão em mod_cluster.

Este não é mais o caso no JBoss EAP 7.1. Isso pode ter conseqüências inesperadas se você estiver esperando que o contexto raiz seja desativado. Por exemplo, as solicitações podem ser desviadas para nós indesejados ou um aplicativo particular que não deve ser exposto pode ser acessado inadvertidamente por meio de um proxy público. As localizações inferiores também são registradas com o balanceador de carga mod_cluster automaticamente, a menos que sejam explicitamente excluídas.

Use o seguinte comando CLI de gerenciamento para excluir ROOT do modcluster configuração do subsistema.

/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=excluded-contexts,value=ROOT)

/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=excluded-contexts,value=ROOT)

Use o seguinte comando da CLI de gerenciamento para desativar o aplicativo da web de boas-vindas padrão.

/subsystem=undertow/server=default-server/host=default-host/location=\/:remove
/subsystem=undertow/configuration=handler/file=welcome-content:remove
reload

/subsystem=undertow/server=default-server/host=default-host/location=\/:remove
/subsystem=undertow/configuration=handler/file=welcome-content:remove
reload

Para obter mais informações sobre como configurar o aplicativo da Web de boas-vindas padrão, consulte Configurar o aplicativo da Web de boas-vindas padrão no Guia de desenvolvimento para o JBoss EAP.

Na configuração padrão do JBoss EAP 6, os JGroups usaram o public interface definida no <interfaces> seção do arquivo de configuração do servidor.

Como é uma prática recomendada usar uma interface de rede dedicada, o JGroups agora usa o novo padrão private interface que é definida no <interfaces> seção do arquivo de configuração do servidor no JBoss EAP 7.

O JGroups fornece suporte de comunicação de grupo para serviços de alta disponibilidade na forma de canais do JGroups. O JBoss EAP 7 apresenta <channel> elementos para o jgroups subsistema no arquivo de configuração do servidor. Você pode adicionar, remover ou alterar a configuração de canais do JGroups usando a CLI de gerenciamento.

Para obter mais informações sobre como configurar JGroups, consulte Comunicação de Cluster com JGroups no JBoss EAP Guia de configuração.

No JBoss EAP 6, os caches clusterizados padrão para replicação de sessão da web e replicação EJB foram replicados ASYNC caches. Isso mudou no JBoss EAP 7. Os caches clusterizados padrão agora são distribuídos ASYNC caches. Os caches replicados não são mais configurados por padrão. Vejo Configurar o modo de cache no JBoss EAP Guia de configuração para obter informações sobre como adicionar um cache replicado e torná-lo o padrão.

Isso só afeta você quando você usa a nova configuração padrão do JBoss EAP 7. Se você migrar a configuração do JBoss EAP 6, a configuração do infinispan subsistema será preservado.

O comportamento de ASYNC A estratégia de cache mudou no JBoss EAP 7.

No JBoss EAP 6, ASYNC Leituras de cache eram livres de bloqueio. Embora eles nunca fossem bloqueados, eles eram propensos a leituras sujas de dados obsoletos, por exemplo, em failover. Isso ocorre porque permitiria solicitações subsequentes para o mesmo usuário iniciar antes que a solicitação anterior fosse concluída. Essa permissividade não é aceitável ao usar o modo distribuído, já que as alterações da topologia de cluster podem afetar a afinidade da sessão e facilmente resultar em dados obsoletos.

No JBoss EAP 7, ASYNC leituras de cache exigem bloqueios. Como agora bloqueiam novas solicitações do mesmo usuário até que a replicação anterior termine, leituras sujas são evitadas.

Esteja ciente das seguintes restrições ao configurar um cache SFSB personalizado para passivação no JBoss EAP 7.1.

Uma mudança de comportamento entre o JBoss EAP 7.0 e o JBoss EAP 7.1 requer que quaisquer atualizações no protocolo de transporte do contêiner de cache sejam feitas no modo batch ou usando um cabeçalho especial. Essa mudança de comportamento também afeta quaisquer ferramentas usadas para gerenciar o servidor do JBoss EAP.

A seguir, um exemplo dos comandos CLI de gerenciamento usados ​​para configurar o protocolo de transporte do contêiner de cache no JBoss EAP 7.0.

/subsystem=infinispan/cache-container=my:add()
/subsystem=infinispan/cache-container=my/transport=jgroups:add()
/subsystem=infinispan/cache-container=my/invalidation-cache=mycache:add(mode=SYNC)

/subsystem=infinispan/cache-container=my:add()
/subsystem=infinispan/cache-container=my/transport=jgroups:add()
/subsystem=infinispan/cache-container=my/invalidation-cache=mycache:add(mode=SYNC)

A seguir, um exemplo dos comandos CLI de gerenciamento necessários para executar a mesma configuração no JBoss EAP 7.1. Note que os comandos são executados em modo batch.

batch
/subsystem=infinispan/cache-container=my:add()
/subsystem=infinispan/cache-container=my/transport=jgroups:add()
/subsystem=infinispan/cache-container=my/invalidation-cache=mycache:add(mode=SYNC)
run-batch

batch
/subsystem=infinispan/cache-container=my:add()
/subsystem=infinispan/cache-container=my/transport=jgroups:add()
/subsystem=infinispan/cache-container=my/invalidation-cache=mycache:add(mode=SYNC)
run-batch

Se preferir não usar o modo batch, você pode especificar o cabeçalho da operação allow-resource-service-restart=true ao definir o transporte. Esteja ciente de que isso reinicia o serviço para que as operações entrem em vigor, e alguns serviços podem parar de funcionar até que o serviço seja reiniciado.

Se você usar scripts para atualizar o protocolo de transporte do contêiner de cache, não deixe de revisá-los e adicionar o modo em lote.

o org.jboss.as.messaging extensão de módulo, localizada em EAP_HOME/modules/system/layers/base/, foi substituído pelo org.wildfly.extension.messaging-activemq módulo de extensão.

o urn:jboss:domain:messaging:3.0 o namespace de configuração do subsistema foi substituído pelo urn:jboss:domain:messaging-activemq:2.0 namespace.

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

Na maioria dos casos, houve um empenho para manter o quanto mais possível a similaridade dos nomes de elementos e de atributos daqueles utilizados nas versões prévias. A seguinte tabela lista algumas das alterações.

As operações de gerenciamento invocadas no novo messaging-activemq subsistema mudou de /subsystem=messaging/hornetq-server= para /subsystem=messaging-activemq/server=.

Você pode migrar um JBoss EAP 6 existente messaging configuração do subsistema para o messaging-activemq subsistema em um servidor JBoss EAP 7 invocando sua migrate Operação.

/subsystem=messaging:migrate

/subsystem=messaging:migrate

Antes de executar o migrate operação, você pode invocar o describe-migration operação para revisar a lista de operações de gerenciamento que serão executadas para migrar do JBoss EAP 6 existente messaging configuração do subsistema para o messaging-activemq subsistema no servidor do JBoss EAP 7.

/subsystem=messaging:describe-migration

/subsystem=messaging:describe-migration

o migrate e describe-migration operações também exibem uma lista de migration-warnings para recursos ou atributos que não podem ser migrados automaticamente.

Avisos para a operação de migração de subsistema de mensagem [Esta é uma tradução automática]

o describe-migration e migrate operações para o messaging subsistema fornece um argumento de configuração adicional. Se você deseja configurar o sistema de mensagens para permitir que clientes legados do JBoss EAP 6 se conectem ao servidor do JBoss EAP 7, você pode adicionar o sistema de mensagens booleano. add-legacy-entries argumento para o describe-migration ou migrate operação da seguinte forma.

/subsystem=messaging:describe-migration(add-legacy-entries=true)
/subsystem=messaging:migrate(add-legacy-entries=true)

/subsystem=messaging:describe-migration(add-legacy-entries=true)
/subsystem=messaging:migrate(add-legacy-entries=true)

Se o argumento booleano add-legacy-entries está configurado para true, a messaging-activemq subsistema cria o legacy-connection-factory recurso e adiciona legacy-entries ao jms-queue e jms-topic Recursos.

Se o argumento booleano add-legacy-entries está configurado para false, nenhum recurso legado é criado no messaging-activemq subsistemas e clientes JMS legados não poderão se comunicar com os servidores do JBoss EAP 7. Este é o valor padrão.

Para obter mais informações sobre compatibilidade com versões anteriores e futuras, consulte Compatibilidade para trás e para frente dentro Configurando o Messaging para o JBoss EAP.

Para mais informações sobre o CLI de gerenciamento migrate e describe-migration operações, consulte Operação de Migração do CLI de Gerenciamento.

Alteração de comportamento de atributo forward-when-no-consumers

O comportamento do forward-when-no-consumers atributo foi alterado no JBoss EAP 7.

No JBoss EAP 6, quando forward-when-no-consumers foi definido para false e não havia consumidores em um cluster, as mensagens foram redistribuídas para todos os nós em um cluster.

Este comportamento mudou no JBoss EAP 7. Quando forward-when-no-consumers está configurado para false e não há consumidores em um cluster, as mensagens não são redistribuídas. Em vez disso, eles são mantidos no nó original para o qual foram enviados.

Alteração na diretiva de balanceamento de carga de cluster padrão

A política de balanceamento de carga de cluster padrão foi alterada no JBoss EAP 7.

No JBoss EAP 6, a política de balanceamento de carga de cluster padrão era similar a STRICT, que é como definir o legado forward-when-no-consumers parâmetro para true. No JBoss EAP 7, o padrão é agora ON_DEMAND, que é como definir o legado forward-when-no-consumers parâmetro para false. Para mais informações sobre essas configurações, consulte Atributos de Conexão de Cluster dentro Configurando o Messaging para o JBoss EAP.

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

A configuração XML mudou significativamente com o novo messaging-activemq subsistema, e agora fornece um esquema XML mais consistente com outros subsistemas do JBoss EAP.

É altamente recomendado que você não tente modificar o JBoss EAP messaging configuração XML do subsistema para se adequar ao novo messaging-activemq subsistema. Em vez disso, invoque o subsistema herdado migrate Operação. Esta operação irá escrever a configuração XML do novo messaging-activemq subsistema como parte de sua execução.

Você pode usar uma das seguintes abordagens para migrar dados do sistema de mensagens de um release anterior para o release atual do JBoss EAP.

Devido à mudança do HornetQ para o ActiveMQ Artemis como provedor de suporte JMS, tanto o formato quanto a localização dos dados do sistema de mensagens foram alterados no JBoss EAP 7.0 e posterior. Vejo Mapeando nomes de pastas de mensagens para obter detalhes sobre as alterações nos nomes e locais da pasta de dados do sistema de mensagens entre as versões 6.4 e 7.x.

java -jar -mp MODULE_PATH org.hornetq.exporter MESSAGING_BINDINGS_DIRECTORY MESSAGING_JOURNAL_DIRECTORY MESSAGING_PAGING_DIRECTORY MESSAGING_LARGE_MESSAGES_DIRECTORY > OUTPUT_DATA.xml

$ java -jar -mp MODULE_PATH org.hornetq.exporter MESSAGING_BINDINGS_DIRECTORY MESSAGING_JOURNAL_DIRECTORY MESSAGING_PAGING_DIRECTORY MESSAGING_LARGE_MESSAGES_DIRECTORY > OUTPUT_DATA.xml

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.hornetq.exporter">
    <main-class name="org.hornetq.jms.persistence.impl.journal.XmlDataExporter"/>
    <properties>
        <property name="jboss.api" value="deprecated"/>
    </properties>
    <dependencies>
        <module name="org.hornetq"/>
    </dependencies>
</module>

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.hornetq.exporter">
    <main-class name="org.hornetq.jms.persistence.impl.journal.XmlDataExporter"/>
    <properties>
        <property name="jboss.api" value="deprecated"/>
    </properties>
    <dependencies>
        <module name="org.hornetq"/>
    </dependencies>
</module>

/subsystem=messaging-activemq/server=default/path=journal-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=paging-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=bindings-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=large-messages-directory:resolve-path

/subsystem=messaging-activemq/server=default/path=journal-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=paging-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=bindings-directory:resolve-path
/subsystem=messaging-activemq/server=default/path=large-messages-directory:resolve-path

Nas versões anteriores do JBoss EAP, as filas de destino JMS foram configuradas no <jms-destinations> elemento sob o <hornetq-server> elemento no messaging subsistema.

<hornetq-server>
  ...
  <jms-destinations>
     <jms-queue name="testQueue">
        <entry name="queue/test"/>
         <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
  </jms-destinations>
  ...
</hornetq-server>

<hornetq-server>
  ...
  <jms-destinations>
     <jms-queue name="testQueue">
        <entry name="queue/test"/>
         <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
  </jms-destinations>
  ...
</hornetq-server>

No JBoss EAP 7, a fila de destino do JMS é configurada no padrão <server> elemento do messaging-activemq subsistema.

<server name="default">
  ...
  <jms-queue name="testQueue" entries="queue/test java:jboss/exported/jms/queue/test"/>
  ...
</server>

<server name="default">
  ...
  <jms-queue name="testQueue" entries="queue/test java:jboss/exported/jms/queue/test"/>
  ...
</server>

Interceptores de mensagem foram alterados significativamente no JBoss EAP 7 com a substituição do HornetQ pelo ActiveMQ Artemis como o provedor de mensagem JMS.

O HornetQ messaging Um subsistema incluído no lançamento anterior do JBoss EAP requeria que você instalasse os interceptores HornetQ adicionando-os a um JAR e então modificando o HornetQ module.xml Arquivo.

o messaging-activemq subsistema incluído no JBoss EAP 7 não requer modificação de um module.xml Arquivo. Classes de interceptadores do usuário, que agora implementam o Apache ActiveMQ Artemis Interceptor interface, agora pode ser carregado de qualquer módulo do servidor. Você especifica o módulo do qual o interceptador deve ser carregado no messaging-activemq subsistema do arquivo de configuração do servidor.

<subsystem xmlns="urn:jboss:domain:messaging-activemq:2.0">
  <server name="default">
    ...
    <incoming-interceptors>
      <class name="com.mycompany.incoming.myInterceptor" module="com.mycompany" />
      <class name="com.othercompany.incoming.myOtherInterceptor" module="com.othercompany" />
    </incoming-interceptors>
    <outgoing-interceptors>
      <class name="com.mycompany.outgoing.myInterceptor" module="com.mycompany" />
      <class name="com.othercompany.outgoing.myOtherInterceptor" module="com.othercompany" />
    </outgoing-interceptors>
  </server>
</subsystem>

<subsystem xmlns="urn:jboss:domain:messaging-activemq:2.0">
  <server name="default">
    ...
    <incoming-interceptors>
      <class name="com.mycompany.incoming.myInterceptor" module="com.mycompany" />
      <class name="com.othercompany.incoming.myOtherInterceptor" module="com.othercompany" />
    </incoming-interceptors>
    <outgoing-interceptors>
      <class name="com.mycompany.outgoing.myInterceptor" module="com.mycompany" />
      <class name="com.othercompany.outgoing.myOtherInterceptor" module="com.othercompany" />
    </outgoing-interceptors>
  </server>
</subsystem>

No JBoss EAP 6, você poderia configurar um mecanismo de servlet para trabalhar com o transporte Netty Servlet. Como o ActiveMQ Artemis substitui o HornetQ como o provedor de mensagens integrado no JBoss EAP 7, essa configuração não está mais disponível. Você deve substituir a configuração de servlet para usar os novos conectores HTTP de mensagens e os aceitadores HTTP.

A maneira como você configura um adaptador de recursos JMS genérico para uso com um provedor JMS de terceiros foi alterada no JBoss EAP 7. Para obter mais informações, consulte Implantando um Adaptador de Recursos JMS Genérico dentro Configurando o Messaging para o JBoss EAP.

No JBoss EAP 7.0, se você configurou o replication-master política sem especificar o check-for-live-server atributo, seu valor padrão era false. Isso mudou no JBoss EAP 7.1. O valor padrão para o check-for-live-server atributo é agora true.

A seguir, um exemplo de um comando da CLI de gerenciamento que configura replication-master política sem especificar o check-for-live-server atributo.

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:add(cluster-name=my-cluster,group-name=group1)

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:add(cluster-name=my-cluster,group-name=group1)

Quando você lê o recurso usando a CLI de gerenciamento, observe que check-for-live-server o valor do atributo está definido como true.

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "check-for-live-server" => true,
        "cluster-name" => "my-cluster",
        "group-name" => "group1",
        "initial-replication-sync-timeout" => 30000L
    },
    "response-headers" => {"process-state" => "reload-required"}
}

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "check-for-live-server" => true,
        "cluster-name" => "my-cluster",
        "group-name" => "group1",
        "initial-replication-sync-timeout" => 30000L
    },
    "response-headers" => {"process-state" => "reload-required"}
}

o serialVersionUID do javax.jms.JMSException mudou entre o JMS 1.1 e o JMS 2.0.0. Isso significa que, se uma instância de um JMSException, ou qualquer uma de suas subclasses, é serializado usando o JMS 1.1, não pode ser desserializado usando o JMS 2.0.0. O contrário também é verdade. Se uma instância de JMSException é serializado usando o JMS 2.0.0, ele não pode ser desserializado usando o JMS 1.1. Em ambos os casos, lança uma exceção semelhante à seguinte:

javax.jms.JMSException: javax.jms.JMSException; local class incompatible: stream classdesc serialVersionUID = 8951994251593378324, local class serialVersionUID = 2368476267211489441

javax.jms.JMSException: javax.jms.JMSException; local class incompatible: stream classdesc serialVersionUID = 8951994251593378324, local class serialVersionUID = 2368476267211489441

Esse problema foi corrigido na versão de manutenção do JMS 2.0.1.

Implementação do JMS para cada versão do JBoss EAP [Esta é uma tradução automática]

Esteja ciente de que o serialVersionUID incompatibilidade pode resultar em um problema de migração nas seguintes situações:

Note que se você enviar uma mensagem que contenha JMSException Usando um cliente do JBoss EAP 6.4, migre seus dados do sistema de mensagens para o JBoss EAP 7.1 e tente desserializar essa mensagem usando um cliente do JBoss EAP 7.1, a desserialização será bem sucedida porque o serialVersionUID no JMS 1.1 é compatível com o do JMS 2.0.1.

Quando você configurou uma fonte de dados no release anterior do JBoss EAP, o valor especificado para o nome do driver dependia do número de classes listadas no META-INF/services/java.sql.Driver arquivo contido no JAR do driver JDBC.

Driver contendo uma classe única

Se o META-INF/services/java.sql.Driver arquivo especificado apenas uma classe, o valor do nome do driver era simplesmente o nome do JAR do driver JDBC. Isto não mudou no JBoss EAP 7.

Driver contendo classes múltiplas

IIn JBoss EAP 6, se houvesse mais de uma classe listada no META-INF/services/java.sql.Driver arquivo, você especificou qual classe era a classe do driver, anexando seu nome ao nome do JAR, juntamente com a versão principal e secundária, no seguinte formato.

JAR_NAME + DRIVER_CLASS_NAME + "_" + MAJOR_VERSION + "_" + MINOR_VERSION

JAR_NAME + DRIVER_CLASS_NAME + "_" + MAJOR_VERSION + "_" + MINOR_VERSION

No JBoss EAP 7, isto mudou. Você agora especifica o nome do driver utilizando o seguinte formato.

JAR_NAME + "_" + DRIVER_CLASS_NAME + "_" + MAJOR_VERSION + "_" + MINOR_VERSION

JAR_NAME + "_" + DRIVER_CLASS_NAME + "_" + MAJOR_VERSION + "_" + MINOR_VERSION

O driver JDBC do MySQL 5.1.31 é um exemplo de um driver que contém duas classes. O nome da classe do driver é com.mysql.jdbc.Driver. Os exemplos a seguir demonstram as diferenças entre como você especifica o nome do driver na versão anterior e atual do JBoss EAP.

mysql-connector-java-5.1.31-bin.jarcom.mysql.jdbc.Driver_5_1

mysql-connector-java-5.1.31-bin.jarcom.mysql.jdbc.Driver_5_1

mysql-connector-java-5.1.31-bin.jar_com.mysql.jdbc.Driver_5_1

mysql-connector-java-5.1.31-bin.jar_com.mysql.jdbc.Driver_5_1

Mudanças no Comportamento de Segurança Legado entre o JBoss EAP 7.0 e o JBoss EAP 7.1 [Esta é uma tradução automática]

Ao usar regiões de segurança legadas, o JBoss EAP 7.1 fornece a geração automática de um certificado autoassinado para fins de desenvolvimento. Este recurso, que não estava disponível no JBoss EAP 7.0, é ativado por padrão. Isso significa que, se você estiver executando no modo FIPS, deverá configurar o servidor para desativar a criação automática de certificado autoassinado. Caso contrário, você poderá ver o seguinte erro ao iniciar o servidor.

ERROR [org.xnio.listener] (default I/O-6) XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException: WFLYDM0114: Failed to lazily initialize SSL context
...
Caused by: java.lang.RuntimeException: WFLYDM0112: Failed to generate self signed certificate
...
Caused by: java.security.KeyStoreException: Cannot get key bytes, not PKCS#8 encoded

ERROR [org.xnio.listener] (default I/O-6) XNIO001007: A channel event listener threw an exception: java.lang.RuntimeException: WFLYDM0114: Failed to lazily initialize SSL context
...
Caused by: java.lang.RuntimeException: WFLYDM0112: Failed to generate self signed certificate
...
Caused by: java.security.KeyStoreException: Cannot get key bytes, not PKCS#8 encoded

Para obter informações sobre criação automática de certificado autoassinado, consulte Criação automática de certificado autoassinado para aplicativos dentro Como configurar a segurança do servidor para o JBoss EAP.

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>

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

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

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)

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>

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

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

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

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

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

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

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.