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>

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>

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>

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

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\")
    ]
}"
    ]}
}

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>

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

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>

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;"/>

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;"/>

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>

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)

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"],
         ...
    }
}

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")

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" => [],
         ...
    }
}

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)

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

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)

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

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

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

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)

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

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

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>

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>

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>

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)

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"}
}

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

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

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

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

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.