Capítulo 4. Mudanças de configuração de servidor

4.1. Opções de migração de configuração de servidor

Para migrar sua configuração de servidor do JBoss EAP 6 para JBoss EAP 7, você pode utilizar a ferramenta de migração do servidor JBoss ou fazer uma migração manual com o auxílio da operação migrate da CLI de gerenciamento.

Ferramenta de migração de servidor JBoss

A ferramenta de migração de servidor JBoss, que está atualmente em desenvolvimento, será o método preferido para atualizar sua configuração para incluir os novos recursos e configurações no JBoss EAP 7 enquanto mantém sua configuração existente.

Operação de migração da CLI de gerenciamento

Você pode utilizar a operação migrate da CLI de gerenciamento para atualizar os subsistemas jacorb, messaging e web no arquivo de configuração do servidor JBoss EAP 6 para permitir que executem na nova versão, mas esteja ciente de que o resultado não é uma configuração completa JBoss EAP 7. Por exemplo:

  • A operação não atualiza o protocolo original remoto e configurações de porta para o novo http-remoting e novas configurações de porta utilizadas agora no JBoss EAP 7.
  • A configuração não inclui os novos subsistemas de JBoss EAP ou funcionalidades tais como implantações singleton clusterizadas ou desligamento ordenado.
  • A configuração não inclui os novos recursos de Java EE 7 como processamento batch.
  • A operação migrate não migra as configurações do subsistema ejb3. Para informação sobre possíveis problemas com migração de EJB , consulte EJB Server Configuration Changes.

Para mais informação sobre como utilizar a operação migrate para migração da configuração do servidor, consulte Operação de migração da CLI de gerenciamento.

4.2. Operação de migração da CLI de gerenciamento

Você pode utilizar a CLI de gerenciamento para atualizar seus arquivos de configurações do servidor JBoss EAP 6 para executar em JBoss EAP 7. A CLI de gerenciamento fornece uma operação de migração para atualizar automaticamente os subsistemas jacorb, messaginge web da versão anterior para a nova configuração. Você pode também executar a operação describe-migration para os subsistemas jacorb, messagingeweb para revisar as mudanças de configuração de migração propostas, antes que você execute a migração. Não há substitutos para os subsistemas cmp, jaxr outhreads e eles devem ser removidos das configurações do servidor.

Importante

Consulte as Opções de migração de configurações de servidor para limitações da operação migrate. A ferramenta de migração do servidor JBoss, que está atualmente em desenvolvimento, será o método preferido para atualizar sua configuração para incluir os novos recursos e configurações em JBoss EAP 7 enquanto mantém sua configuração existentes.

Tabela 4.1. Migração de subsistemas e operação de Cli de gerenciamento

Subsistema JBoss EAP 6Subsistema JBoss EAP 7Operação de CLI de gerenciamento

cmp

sem substitução

remove

jacorb

iiop-openjdk

migrate

jaxr

sem substitução

remove

messaging

messaging-activemq

migrate

threads

sem substitução

remove

web

undertow

migrate

Inicie o servidor e a CLI de gerenciamento

Siga as etapas abaixo para atualizar sua configuração do servidor JBoss EAP 6 para executar em JBoss EAP 7.

  1. Antes de começar, verifique Backup de dados importantes e revisão do estado do servidor . Isto contém informações importantes sobre a verificação do bom estado do servidor e o backup de arquivos adequados.
  2. Inicie o servidor JBoss EAP 7 com a configuração do JBoss EAP 6.

    1. Faça o backup dos arquivos do servidor JBoss EAP 7.
    2. Copie o arquivo de configuração da versão anterior no diretório do JBoss EAP 7.

      $ cp EAP6_HOME/standalone/configuration/standalone-full.xml EAP7_HOME/standalone/configuration
    3. Navegue para o diretório de instalação do JBoss EAP 7 e inicie o servidor com o argumento --admin-only.

      $ bin/standalone.sh -c standalone-full.xml --admin-only
      Nota

      Você irá ver os seguintes ERROS org.jboss.as.controller.management-operation no registro do servidor quando você iniciar o servidor. Esses erros são previstos e indicam que as configurações de subsistemas legados devem ser removidas ou migradas para o JBoss EAP 7.

      • WFLYCTL0402: Subsistemas [cmp] fornecidos por extensão legada 'org.jboss.as.cmp' não têm suporte nos servidores executando esta versão. Ambos o subsistema e a extensão devem ser removidos ou migrados antes que o servidor funcione.
      • WFLYCTL0402: Subsistemas [jacorb] fornecidos por extensão legada 'org.jboss.as.jacorb' não têm suporte em servidores executando esta versão. Ambos o subsistema e a extensão devem ser removidos ou migrados antes que o servidor funcione.
      • WFLYCTL0402: Subsistemas [jaxr] fornecidos por extensão legada 'org.jboss.as.jaxr' não têm suporte nos servidores executando esta versão. Ambos o subsistema e a extensão devem ser removidos ou migrados antes que o servidor funcione.
      • WFLYCTL0402: Subsistemas [messaging] fornecidos por extensão legada 'org.jboss.as.messaging' não têm suporte nos servidores executando esta versão. Ambos o subsistema e a extensão devem ser removidos ou migrados antes que o servidor funcione.
      • WFLYCTL0402: Subsistemas [threads] fornecidos por extensão legada 'org.jboss.as.threads' não têm suporte nos servidores executando esta versão. Ambos o subsistema e a extensão devem ser removidos ou migrados antes que o servidor funcione.
      • WFLYCTL0402: Subsistemas [web] fornecidos por extensão legada 'org.jboss.as.web' não têm suporte nos servidores executando esta versão. Ambos o subsistema e a extensão devem ser removidos ou migrados antes que o servidor funcione.
  3. Abra um novo terminal, navegue para o diretório de instalação do JBoss EAP 7 e inicie a CLI de gerenciamento utilizando os argumentos --controller=remote://localhost:9999.

    $ bin/jboss-cli.sh --connect --controller=remote://localhost:9999

Migrar JacORB, Messaging e subsistemas Web

  1. Para revisar as alterações de configurações que serão efetuadas ao subsistema antes de você realizar a migração, execute a operação describe-migration.

    A operação describe-migration utiliza a seguinte sintaxe.

    /subsystem=SUBSYSTEM_NAME:describe-migration

    O exemplo seguinte descreve as alterações de configuração que serão efetuadas no arquivo de configuração do standalone-full.xml do JBoss EAP 6.4 quando for migrado para JBoss EAP 7. As entradas foram removidas da saída para melhorar legibilidade e economizar espaço.

    Exemplo: operação describe-migration

    [standalone@localhost:9999 /] /subsystem=messaging:describe-migration
    {
        "outcome" => "success",
        "result" => {
            "migration-warnings" => [],
            "migration-operations" => [
                {
                    "operation" => "add",
                    "address" => [("extension" => "org.wildfly.extension.messaging-activemq")],
                    "module" => "org.wildfly.extension.messaging-activemq"
                },
                {
                    "operation" => "add",
                    "address" => [("subsystem" => "messaging-activemq")]
                },
                <!-- *** Entries removed for readability *** -->
                {
                    "operation" => "remove",
                    "address" => [("subsystem" => "messaging")]
                },
                {
                    "operation" => "remove",
                    "address" => [("extension" => "org.jboss.as.messaging")]
                }
            ]
        }
    }

  2. Execute a operação migrate para migrar a configuração do subsistema para o subsistema que o substitui no JBoss EAP 7. A operação utiliza a seguinte sintaxe.

    /subsystem=SUBSYSTEM_NAME:migrate
    Nota

    O subsistema messaging describe-migration e operações migrate permitem que você passe um argumento para configurar acesso pelo cliente legado. Para mais informções sobre a sintaxe do comando, consulte Messaging Subsystem Migration and Forward Compatibility.

  3. Verifique o desfecho e o resultado do comando. Certifique-se que a operação foi completada com êxito e não há entradas de "migration-warning". Isto significa que a configuração de migração para o subsistema está completa.

    Exemplo: operação de migração com êxito sem alertas

    [standalone@localhost:9999 /] /subsystem=messaging:migrate
    {
        "outcome" => "success",
        "result" => {"migration-warnings" => []}
    }

    Se você vir entradas "migration-warnings" no registro, isto indica que a migração das configurações do servidor foram completadas com sucesso porém não foi possível migrar todos os elementos e atributos. Você deve seguir as sugestões fornecidas pelos "migration-warnings" e executar comandos suplementares da CLI de gerenciamento para modificar essas configurações. O que segue é um exemplo de uma operaçãomigrate que retorna "migration-warnings".

    Examplo: operação de migração com alertas

    [standalone@localhost:9999 /] /subsystem=messaging:migrate
    {
        "outcome" => "success",
        "result" => {"migration-warnings" => [
            "WFLYMSG0080: Could not migrate attribute group-address from resource [
        (\"subsystem\" => \"messaging-activemq\"),
        (\"server\" => \"default\"),
        (\"broadcast-group\" => \"groupB\")
    ]. Use instead the socket-binding attribute to configure this broadcast-group.",
            "WFLYMSG0080: Could not migrate attribute group-port from resource [
        (\"subsystem\" => \"messaging-activemq\"),
        (\"server\" => \"default\"),
        (\"broadcast-group\" => \"groupB\")
    ]. Use instead the socket-binding attribute to configure this broadcast-group.",
            "WFLYMSG0080: Could not migrate attribute local-bind-address from resource [
        (\"subsystem\" => \"messaging-activemq\"),
        (\"server\" => \"default\"),
        (\"broadcast-group\" => \"groupA\")
    ]. Use instead the socket-binding attribute to configure this broadcast-group.",
            "WFLYMSG0080: Could not migrate attribute local-bind-port from resource [
        (\"subsystem\" => \"messaging-activemq\"),
        (\"server\" => \"default\"),
        (\"broadcast-group\" => \"groupA\")
    ]. Use instead the socket-binding attribute to configure this broadcast-group.",
            "WFLYMSG0080: Could not migrate attribute group-address from resource [
        (\"subsystem\" => \"messaging-activemq\"),
        (\"server\" => \"default\"),
        (\"broadcast-group\" => \"groupA\")
    ]. Use instead the socket-binding attribute to configure this broadcast-group.",
            "WFLYMSG0080: Could not migrate attribute group-port from resource [
        (\"subsystem\" => \"messaging-activemq\"),
        (\"server\" => \"default\"),
        (\"broadcast-group\" => \"groupA\")
    ]. Use instead the socket-binding attribute to configure this broadcast-group."
        ]}
    }

    Nota

    A lista de alertas migrate e describe-migration para cada subsistema está localizada no Material de Referência no final deste guia.

  4. Revise o arquivo de configuração de servidor para verificar se extensão, subsistema e espaço de nomes foram atualizados e as configurações dos subsistemas existentes foram migradas para o JBoss EAP 7.

    Nota

    Você deve repetir este processo para cada um dos subsistemas jacorb, messaging e web, usando os seguintes comandos.

    /subsystem=jacorb:migrate
    /subsystem=messaging:migrate
    /subsystem=web:migrate
  5. Remova os subsistemas cmp, jaxr e threads e extensões da configuração do servidor.

    Enquanto ainda no prompt de comando da CLI de gerenciamento, remova os subsistemas obsoletos cmp, jaxr e threads executando os seguintes comandos.

    /subsystem=cmp:remove
    /extension=org.jboss.as.cmp:remove
    /subsystem=jaxr:remove
    /extension=org.jboss.as.jaxr:remove
    /subsystem=threads:remove
    /extension=org.jboss.as.threads:remove
Importante

Você deve migrar os subsistemas messaging, jacorb e web e remover as extensões e subsistemas cmp, jaxr, e threads antes de reiniciar o servidor para operação normal. Se você precisar reiniciar o servidor antes de completar este processo, certifique-se de que incluiu o argumento --admin-only na linha de comando do início do servidor. Isto permitirá que você continue com as alterações de configuração.

4.3. Alterações de prefixos dos registros de mensagens

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.

For a complete list of the new log message project code prefixes used in JBoss EAP 7, see Project Codes Used in JBoss EAP in the JBoss EAP Development Guide.

4.4. Alterações de configurações do servidor web

4.4.1. Substituição do subsistema web com Undertow

O Undertow substitui JBoss Web como um servidor web no JBoss EAP 7. Isto significa que a configuração do subsistema web legada deve ser migrada para a nova configuração de subsistema undertow do JBoss EAP 7.

  • Os espaço de nomes da configuração de subsistema urn:jboss:domain:web:2.2 no arquivo de configuração do servidor foi substituído pelo espaço de nomes urn:jboss:domain:undertow:3.1 .
  • O módulo de extensão org.jboss.as.web, localizado em EAP_HOME/modules/system/layers/base/, foi substituído pelo módulo de extensão org.wildfly.extension.undertow.

Você pode utilizar a operação migrate da CLI de gerenciamento para migrar os subsistemas web para undertow no arquivo de configuração do servidor. Porém, esteja ciente que esta operação não é capaz de migrar todas as configurações dos subsistemas do JBoss Web. Se você vir entradas "migration-warning", você deve executar comandos suplementares da CLI de gerenciamento para migrar estas configurações para Undertow. Para mais informações sobre a operação migrate da CLI de gerenciamento, consulte Operação de migração da CLI de gerenciamento..

Segue abaixo um exemplo de configuração de subsistema web padrão 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>

Segue abaixo um exemplo de configuração de subsistema undertow padrão no JBoss EAP 7.

<subsystem xmlns="urn:jboss:domain:undertow:3.1">
    <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>

4.4.2. Migrar as condições de regravação do JBoss Web

A operação migrate da CLI de gerenciamento não é capaz de migrar automaticamente condições de regravação. Elas são relatadas como "migration-warnings" e você deve migrá-las manualmente. Você pode criar a configuração equivalente no JBoss EAP 7 ao utilizar Undertow Predicates Attributes and Handlers.

Segue abaixo um exemplo de configuração de subsistema web no JBoss EAP 6 que inclui configuração rewrite.

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

Siga as instruções da operação de migração da CLI de gerenciamento para iniciar seu servidor e a CLI de gerenciamento, depois migre o arquivo de configuração de subsistema web utilizando o seguinte comando:

/subsystem=web:migrate

Os seguintes "migration-warnings" são relatados quando você executa a operação migrate no 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\")
    ]
}"
    ]}
}

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

Nota

A configuração de regravação foi abandonada.

<subsystem xmlns="urn:jboss:domain:undertow:3.1">
     <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>

Utilize a CLI de gerenciamento para criar o filtro para substituir a configuração de regravação no subsistema undertow. Você deve ver "{"outcome" ⇒ "success"}" 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

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

<subsystem xmlns="urn:jboss:domain:undertow:3.1">
    <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>

For more information about how to configure filters and handlers using the management CLI, see Configuring the Web Server in the JBoss EAP 7 Configuration Guide.

4.4.3. Migrar propriedades de sistemas JBoss Web

Nos lançamentos prévios de JBoss EAP, as propriedades de sistema podiam ser utilizadas para modificar o comportamento padrão de JBoss Web. Para informação sobre como configurar o mesmo comportamento em Undertow, consulte JBoss Web System Properties Migration Reference

4.4.4. Migrate JBoss Web jboss-web.xml Overlay

In JBoss EAP 6, JBoss Web supported the ability to specify additional static files for a web application using the overlay element in the jboss-web.xml file. This feature did not actually overlay existing files, but instead added static files to a deployment outside of the WAR archive.

In the following jboss-web.xml file example, /tmp/mycontents/test.html was returned by the JBoss EAP 6 server when you accessed the URL http://localhost:8080/example/test.html.

<jboss-web>
    <context-root>/example</context-root>
    <overlay>/tmp/mycontents/</overlay>
</jboss-web>

Undertow, which replaces JBoss Web in JBoss EAP 7, does not support the jboss-web.xml file overlay feature.

4.4.5. Migrar válvulas globais

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.

  • Válvula globais são inseridas na pipeline de processamento de solicitações de todos os aplicativos implantados e são configuradas no arquivo de configuração do servidor.
  • Válvulas do autenticador autenticam as credenciais da solicitação.
  • Aplicativos personalizados foram criados através da extensão da classe org.apache.catalina.valves.ValveBase e configurados no elemento <valve> do arquivo descritor jboss-web.xml. Estas válvulas devem ser migradas manualmente.

Esta seção descreve como migrar válvulas globais. Migração de válvulas personalizadas e autenticadoras pode ser consultada na seção Migrate Custom Application Valves 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.

For more information about how to configure handlers, see Configuring Handlers in the JBoss EAP 7 Configuration Guide.

For more information about how to configure filters, see Configuring Filters in the JBoss EAP 7 Configuration Guide.

Migrar válvulas de JBoss Web

A tabela que segue lista as válvulas que foram fornecidas pelo JBoss Web nas versões anteriores do JBoss EAP e manipuladores integrados Undertow correspondentes. As válvulas JBoss Web estão localizadas no pacote org.apache.catalina.valves.

Tabela 4.2. Mapeamento das válvulas para manipuladores

VálvulaManipulador

AccessLogValve

io.undertow.server.handlers.accesslog.AccessLogHandler

CrawlerSessionManagerValve

io.undertow.servlet.handlers.CrawlerSessionManagerHandler

ExtendedAccessLogValve

io.undertow.server.handlers.accesslog.AccessLogHandler

JDBCAccessLogValve

Consulte o JDBCAccessLogValve Manual Migration Procedure abaixo para instruções.

RemoteAddrValve

io.undertow.server.handlers.IPAddressAccessControlHandler

RemoteHostValve

io.undertow.server.handlers.AccessControlListHandler

RemoteIpValve

io.undertow.server.handlers.ProxyPeerAddressHandler

RequestDumperValve

io.undertow.server.handlers.RequestDumpingHandler

RewriteValve

Consulte Migrate JBoss Web Rewrite Conditions para instruções para migrar estas válvulas manualmente.

StuckThreadDetectionValve

io.undertow.server.handlers.StuckThreadDetectionHandler

Você pode utilizar a operação migrate da CLI de gerenciamento para migrar automaticamente válvulas globais que seguem os seguintes critérios:

  • Elas estão limitadas às válvulas listadas na tabela anterior que não necessitam de processamento manual.
  • Elas devem estar definidas no subsistema web do arquivo de configuração do servidor.

Para mais informações sobre a operação migrate da CLI de gerenciamento, consulte Operação de migração da CLI de gerenciamento .

Procedimento de migração manual JDBCAccessLogValve

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

<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>
  1. Crie um módulo de driver para o banco de dados que irá armazenar as entradas de registro.
  2. Configure a fonte de dados para o banco de dados e adicione o driver à lista de drivers disponíveis no subsistema datasources.

    <datasources>
        <datasource jndi-name="java:jboss/datasources/accessLogDS" pool-name="accessLogDS" enabled="true" use-java-context="true">
            <connection-url>jdbc:mysql://localhost:3306/wildfly?zeroDateTimeBehavior=convertToNull</connection-url>
            <driver>mysql</driver>
            <security>
               <user-name>root</user-name>
               <password>Password1!</password>
            </security>
        </datasource>
        ...
        <drivers>
            <driver name="mysql" module="com.mysql">
                <driver-class>com.mysql.jdbc.Driver</driver-class>
            </driver>
        ...
        </drivers>
    </datasources>
  3. Configure um expression-filter no subsistema undertow com a seguinte expressão: jdbc-access-log(datasource=DATASOURCE_JNDI_NAME).

    <filters>
        <expression-filter name="jdbc-access" expression="jdbc-access-log(datasource='java:jboss/datasources/accessLogDS')" />
        ...
    </filters>

4.5. Alterações de configurações do servidor JGroups

4.5.1. JGroups é pre-definido para uma interface de rede privada

Na configuração padrão JBoss EAP 6, JGroups utilizavam a interface public definida na seção <interfaces> do arquivo de configuração do servidor.

Devido a recomendação da prática de utilizar uma interface de rede dedicada, por padrão, agora JGroups utiliza a nova interface private que está definida na seção <interfaces> do arquivo de configuração do servidor no JBoss EAP 7.

4.5.2. Alterações de Canais JGroups

O JGroups fornece suporte de comunicação em grupo para serviços de HA (Alta Disponibilidade) na forma de canais de JGroups. JBoss EAP 7 introduz elementos <channel> ao subsistema jgroups no arquivo de configuração de servidor. Você pode adicionar, remover ou alterar a configuração dos canais JGroup utilizando a CLI de gerenciamento.

For more information about how to configure JGroups, see Cluster Communication with JGroups in the JBoss EAP Configuration Guide.

4.6. Alterações de configuração de servidor Infinispan

4.6.1. Alterações de configurações de cachês por padrão de Infinispan

In JBoss EAP 6, the default clustered caches for web session replication and EJB replication were replicated ASYNC caches. This has changed in JBoss EAP 7. The default clustered caches are now distributed ASYNC caches. The replicated caches are no longer even configured by default. See Configure the Cache Mode in the JBoss EAP Configuration Guide for information about how to add a replicated cache and make it the default.

Isto somente afetará quando você utilizar a nova configuração padrão JBoss EAP 7. Se você migrar a configuração do JBoss EAP 6, a configuração do subsistema infinispan será preservada.

4.6.2. Alterações de estratégia de cachê Infinispan

O comportamento da estratégia de cachê ASYNC foi alterado no JBoss EAP 7.

No JBoss EAP 6, as leituras de cachê ASYNC não eram bloqueadas. Embora elas nunca fossem bloqueadas, elas tendiam às leituras sujas de dados obsoletos, por exemplo na recuperação de falhas ( failover). Isto acontecia porque ela permitia que solicitações subsequentes para o mesmo usuário fossem iniciadas antes que a solicitação anterior tivesse sido finalizada. Esta permissividade não é aceitável quando utilizar modo distribuído, pois as alterações de topologia do cluster podem afetar a afinidade da sessão e facilmente resultar em dados obsoletos.

No JBoss EAP 7, leituras de cachê ASYNC necessitam de bloqueios. Já que agora elas bloqueiam novas solicitação do mesmo usuário até que a replicação prévia seja finalizada, as leituras sujas são evitadas.

4.7. Alterações de configurações de servidor EJB

If you use the management CLI migrate operation to upgrade your existing configuration, you might see exceptions in the server log when you deploy your EJB applications.

Importante

Se você utilizar o JBoss Server Migration Tool para atulizar sua configuração de servidor, o subsistema ejb3 deve ser configurado corretamente e você não deve ter nenhum problema quando você implementar seus aplicativos EJB.

DuplicateServiceException

A seguinte DuplicateServiceException é causada ao fazer a memorização das alterações em JBoss EAP 7.

DuplicateServiceException no log do servidor

ERRO [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Falha ao iniciar serviço jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".cache-dependencies-installer: org.jboss.msc.service.StartException no serviço  jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".cache-dependencies-installer: Falha ao iniciar serviço
...
Causado por: org.jboss.msc.service.DuplicateServiceException: Serviço jboss.infinispan.ejb."mdb-1.0-SNAPSHOT.jar".config já esta registrado

Você deve reconfigurar o cache para resolver este erro.

  1. Siga as instruções para Iniciar o servidor e a CLI de gerenciamento.
  2. Emita os seguintes comandos para reconfigurar memorização no subsistema ejb3.

    /subsystem=ejb3/file-passivation-store=file:remove
    /subsystem=ejb3/cluster-passivation-store=infinispan:remove
    /subsystem=ejb3/passivation-store=infinispan:add(cache-container=ejb, max-size=10000)
    
    /subsystem=ejb3/cache=passivating:remove
    /subsystem=ejb3/cache=clustered:remove
    /subsystem=ejb3/cache=distributable:add(passivation-store=infinispan, aliases=[passivating, clustered])

4.8. Alterações de configuração do servidor de mensagens

No JBoss EAP 7, Active MQ Artemis substitui HornetQ como o fornecedor de suporte JMS. Esta seção descreve como migrar a configuração e dados de mensagens relacionados.

4.8.1. Alterações de configuração do servidor de subsistema de mensagens

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

O espaço de nomes da configuração do subsistema urn:jboss:domain:messaging:3.0 foi substituído pelo espaço de nomes urn:jboss:domain:messaging-activemq:1.0.

Modelo de gerenciamento

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.

Tabela 4.3. Mapeamento dos atributos de mensagens

Nome HornetQNome ActiveMQ

hornetq-server

servidor

Tipo de hornetq-server

serverType

conectores

conector

discovery-group-name

discovery-group

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

Você pode migrar uma configuração existente de subsistema JBoss EAP 6 messaging para o subsistema messaging-activemq em um servidor JBoss EAP 7 invocando a operação migrate.

/subsystem=messaging:migrate

Before you execute the migrate operation, you can invoke the describe-migration operation to review the list of management operations that will be performed to migrate from the existing JBoss EAP 6 messaging subsystem configuration to the messaging-activemq subsystem on the JBoss EAP 7 server.

/subsystem=messaging:describe-migration

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

Migração de subsistema de mensagens e compatibilidade com versões futuras

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

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

Se o argumento booleano add-legacy-entries for definido para true, o subsistema messaging-activemq cria o recurso legacy-connection-factory e adiciona legacy-entries aos recursos jms-queue e jms-topic.

Se o argumento booleano add-legacy-entries for definido false, nenhum recurso legado será criado no subsistema messaging-activemq e clientes JMS legados não conseguirão comunicar-se com o servidor JBoss EAP 7. Este é o valor padrão.

For more information about forward and backward compatibility see the Backward and Forward Compatibility in Configuring Messaging for JBoss EAP.

Para mais informações sobre as operações migrate e describe-migration da CLI de gerenciamento, consulte Operação de migração da CLI de gerenciamento.

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

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

Em JBoss EAP 6, quando forward-when-no-consumers era determinado para false e não haviam consumidores em uma cluster, as mensagens eram redistribuidas para todos os nós em uma cluster.

Este comportamento foi alterado no JBoss EAP 7. Quando forward-when-no-consumers é estabelecido para false e não há consumidores no cluster, as mensagens não são redistribuídas. Ao invés disso, elas são mantidas no nó original ao qual elas foram envidadas.

Configuração XML do subsistema de mensagens

A configuração XML foi alterada significativamente com o novo subsistema messaging-activemq para fornecer um esquema XML mais consistente com outros subsistemas JBoss EAP.

It is strongly advised that you do not attempt to modify the JBoss EAP messaging subsystem XML configuration to conform to the new messaging-activemq subsystem. Instead, invoke the legacy subsystem migrate operation. This operation will write the XML configuration of the new messaging-activemq subsystem as a part of its execution.

4.8.2. Migrar dados de mensagem

Devido à alteração do HornetQ para ActiveMQ Artemis como o provedor de suporte JMS, ambos o formato e a localização dos dados de mensagens foram alterados no JBoss EAP 7.

Você pode usar uma das seguintes abordagens para migrar os dados:

Consulte Mapeamento de nomes de pastas de mensagens para detalhes das alterações de nomes de pasta de dados de mensagem entre as diferentes versões.

4.8.2.1. Migrar dados de mensagens usando exportação e importação

Usando esta abordagem, você exporta os dados do lançamento anterior usando a utilidade exporter do HornetQ. Depois você importa o arquivo de saída de formato XML ao usar a operação import-journal.

Atenção

Há um problema conhecido atualmente com esta abordagem. Para verificar o status mais recente deste problema, consulte JBEAP-4407 - Consumidor falha com IndexOutOfBoundsException quando estiver lendo mensagens grandes de diário importado .

Exportação de dados de mensagens a partir da versão anterior
Importante

O servidor JBoss EAP 6 deve ser interrompido antes de exportar os dados de mensagens.

A utilidade exporterdo HornetQ gera e exporta os dados de mensagens do JBoss EAP 6 para um arquivo de formato XML. Este comando requer que você especifique os caminhos para os HornetQ JARs exigidos que foram remetidos com o JBoss EAP 6 e os caminhos para as pastas messagingbindings/, messagingjournal/, messagingpaging/ e messaginglargemessages/ das versões anteriores como argumentos, e especifique um arquivo de saída no qual irá gravar os dados XML exportados.

Segue a sintaxe exigida pela utilidade exporter do HornetQ.

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

Crie um módulo personalizado para certificar-se que as versões corretas dos JARs HornetQ , incluindo quaisquer JARs instalados com patches ou atualizações, sejam carregadas e estejam disponíveis para a utilidade exporter. Utilizando o seu editor favorito, crie um novo arquivo module.xml no diretórioEAP6_HOME/modules/org/hornetq/exporter/main/ e copie o seguinte conteúdo:

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

O módulo personalizado é criado no diretório modules/, não no diretório modules/system/layers/base/.

Siga os passos abaixo para exportar os dados.

  1. Encerre os processos do servidor JBoss EAP 6.
  2. Crie um módulo personalizado conforme descrito acima.
  3. Execute o seguinte comando para exportar os dados.

    $ java -jar jboss-modules.jar -mp modules/ org.hornetq.exporter standalone/data/messagingbindings/ standalone/data/messagingjournal/ standalone/data/messagingpaging standalone/data/messaginglargemessages/ > OUTPUT_DIRECTORY/OldMessagingData.xml
  4. Certifique-se de que não há erros ou mensagens de aviso no registro na conclusão do comando.
  5. Utilize as ferramentas disponíveis para seu sistema operacional para validar o XML no arquivo de saída gerado.
Importar os dados de mensagens formatados em XML

Em seguida você importa o arquivo de saída formatado em XML utilizando a operação import-journal como segue.

/subsystem=messaging-activemq/server=default:import-journal(file=OUTPUT_DIRECTORY/OldMessagingData.xml)

4.8.2.2. Migrar dados de mensagem usando uma ponte JMS

Usando esta abordagem, você configura e implementa uma ponte JMS ao servidor JBoss EAP 7 que transfere mensagens da fila do HornetQ JBoss EAP 6 para a fila do ActiveMQ Artemis JBoss EAP 7.

Uma ponte JMS consome mensagens a partir de uma fila JMS fonte ou tópico e as envia a uma fila JMS destino ou tópico, que está normalmente em um servidor diferente. Isto pode ser usado como ponte para as mensagens entre quaisquer servidores JMS, contanto que elas sejam compatíveis com o JMS 1.1. Os recursos JMS de destino e fonte são pesquisados usando o JNDI e as classes de cliente para a pesquisa JNDI devem ser empacotadas em um módulo. O nome do módulo é, então, declarado na configuração da ponte JMS.

Esta seção descreve como configurar os servidores e implementar uma ponte JMS para transferir os dados de mensagem do JBoss EAP 6 para o JBoss EAP 7.

Configure o servidor JBoss EAP 6
  1. Encerre os processos do servidor JBoss EAP 6.
  2. Fazendo o back up do diário HornetQ e arquivos de configuração.

  3. Certifique-se que a fila JMS InQueue que contém as mensagens JMS está definida no servidor JBoss EAP 6.
  4. Certifique-se que a configuração do subsistema messaging contém uma entrada para o RemoteConnectionFactory similar ao que segue.

    <connection-factory name="RemoteConnectionFactory">
        <entries>
            <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
        </entries>
        ...
    </connection-factory>

    Se não contiver a entrada, crie uma usando o seguinte comando da CLI de gerenciamento:

    /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:add(factory-type=XA_GENERIC, connector=[netty], entries=[java:jboss/exported/jms/RemoteConnectionFactory],ha=true,block-on-acknowledge=true,retry-interval=1000,retry-interval-multiplier=1.0,reconnect-attempts=-1)
Configure o servidor JBoss EAP 7
  1. A configuração da ponte JMS exige o módulo org.hornetq para conectar-se ao servidor HornetQ na versão anterior. Este módulo e suas dependências diretas não estão presentes no JBoss EAP 7, você deve copiar os seguintes módulos da versão anterior.

    • Copie o módulo org.hornetq para o diretório do JBoss EAP 7 EAP_HOME/modules/org/ .

      • Se você não utilizou patches neste módulo, copie esta pasta do servidor JBoss EAP 6.4: EAP6_HOME/modules/system/layers/base/org/hornetq/
      • Se você utilizou patches neste módulo, copie esta pasta do servidor JBoss EAP 6.4: EAP6_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.x.CP/org/hornetq/
    • Remova o <resource-root> para caminho HornetQ libdo arquivo JBoss EAP 7 EAP_HOME/modules/org/hornetq/main/module.xml.

      • Se você não utilizou patches para o módulo JBoss EAP 6.4 org.hornetq, remova a seguinte linha do arquivo:

        <resource-root path="lib"/>
      • Se você utilizou patches para o módulo de JBoss EAP 6.4 org.hornetq, remova as seguintes linhas do arquivo:

        <resource-root path="lib"/>
        <resource-root path="../../../../../org/hornetq/main/lib"/>
        Atenção

        Falha ao remover o HornetQ lib path resource-root causará a falha da ponte com o seguinte erro no arquivo log.

        2016-07-15 09:32:25,660 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
            ("subsystem" => "messaging-activemq"),
            ("jms-bridge" => "myBridge")
        ]) - descrição da falha: "WFLYMSGAMQ0086: Não foi possível carregar módulo org.hornetq"
    • Copie o módulo org.jboss.nettypara o diretório JBoss EAP 7 EAP_HOME/modules/org/jboss/.

      • Se você não aplicou nenhum patch a este módulo, copie esta pasta do servidor JBoss EAP 6.4: EAP6_HOME/modules/system/layers/base/org/jboss/netty/
      • Se você aplicou patches a este módulo, copie esta pasta do servidor JBoss EAP 6.4: EAP6_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.x.CP/org/jboss/netty
  2. Crie a fila JMS para conter as mensagens recebidas do servidor JBoss EAP 6. O que segue é um exemplo de um comando da CLI de gerenciamento que cria a fila JMS MigratedMessagesQueue para receber a mensagem.

    jms-queue add --queue-address=MigratedMessagesQueue --entries=[jms/queue/MigratedMessagesQueue java:jboss/exported/jms/queue/MigratedMessagesQueue]

    Isto cria a seguinte configuração jms-queue para o servidor padrão no subsistema messaging-activemq do servidor JBoss EAP 7.

    <jms-queue name="MigratedMessagesQueue" entries="jms/queue/MigratedMessagesQueue java:jboss/exported/jms/queue/MigratedMessagesQueue"/>
  3. Certifique-se de que o servidorpadrão do subsistema messaging-activemq contém uma configuração para o InVmConnectionFactory connection-factory similar ao que segue:

    <connection-factory name="InVmConnectionFactory" factory-type="XA_GENERIC" entries="java:/ConnectionFactory" connectors="in-vm"/>

    Se não contiver a entrada, crie uma usando o seguinte comando da CLI de gerenciamento:

    /subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:add(factory-type=XA_GENERIC, connectors=[in-vm], entries=[java:/ConnectionFactory])
  4. Crie e implemente uma ponte JMS que lê mensagens a partir da fila JMS InQueue configurada no servidor JBoss EAP 6 e as transfere ao MigratedMessagesQueue configurado no servidor JBoss EAP 7.

    /subsystem=messaging-activemq/jms-bridge=myBridge:add(add-messageID-in-header=true,max-batch-time=100,max-batch-size=10,max-retries=-1,failure-retry-interval=1000,quality-of-service=AT_MOST_ONCE,module=org.hornetq,source-destination=jms/queue/InQueue,source-connection-factory=jms/RemoteConnectionFactory,source-context=[("java.naming.factory.initial"=>"org.jboss.naming.remote.client.InitialContextFactory"),("java.naming.provider.url"=>"remote://127.0.0.1:4447")],target-destination=jms/queue/MigratedMessagesQueue,target-connection-factory=java:/ConnectionFactory)

    Isto cria a seguinte configuração jms-bridge no subsistema messaging-activemq do servidor JBoss EAP 7.

    <jms-bridge name="myBridge" add-messageID-in-header="true" max-batch-time="100" max-batch-size="10" max-retries="-1" failure-retry-interval="1000" quality-of-service="AT_MOST_ONCE" module="org.hornetq">
        <source destination="jms/queue/InQueue" connection-factory="jms/RemoteConnectionFactory">
            <source-context>
                <property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
                <property name="java.naming.provider.url" value="remote://127.0.0.1:4447"/>
            </source-context>
        </source>
        <target destination="jms/queue/MigratedMessagesQueue" connection-factory="java:/ConnectionFactory"/>
    </jms-bridge>
  5. Se a segurança está configurada para JBoss EAP 6, você deve também configurar o elemento <source> de configuração da ponte JMS para incluir um source-context que especifique o nome de usuário correto e a senha para usar na pesquisa JNDI quando criar uma conexão.
Migrar os dados
  1. Verifique se a informação que você forneceu para a seguinte configuração está correta.

    • Qualquer nome tópico e fila
    • A java.naming.provider.url para pesquisa JNDI
  2. Certifique-se que você implantou a destinação JMS alvo para o servidor JBoss EAP 7.
  3. Inicie ambos os servidores JBoss EAP 6 e JBoss EAP 7.

4.8.2.3. Mapeamento dos nomes da pasta de mensagens

A tabela seguinte mostra os nomes dos diretórios de mensagem utilizados nas versões anteriores e os nomes correspondentes utilizados no lançamento atual do JBoss EAP. Os diretórios são referentes ao diretório jboss.server.data.dir, cujo padrão é EAP_HOME/standalone/data/ caso não seja especificado.

Nome de diretório JBoss EAP 6Nome de diretório JBoss EAP 7

messagingbindings/

activemq/bindings/

messagingjournal/

activemq/journal/

messaginglargemessages/

activemq/largemessages/

messagingpaging/

activemq/paging/

Nota

The messaginglargemessages/ and messagingpaging/ directories might not be present if there are no large messages or if paging is disabled.

4.8.3. Migrar as destinações JMS

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

<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 JMS é configurada no elemento padrão <server> do subsistema messaging-activemq.

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

4.8.4. Migrar interceptores de mensagem

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 subsistema messaging do HornetQ incluído na versão anterior do JBoss EAP exigia que você instalasse os interceptores HornetQ ao adicioná-los a um JAR e depois modificar o arquivo module.xml do HornetQ.

The messaging-activemq subsystem included in JBoss EAP 7 does not require modification of a module.xml file. User interceptor classes, which now implement the Apache ActiveMQ Artemis Interceptor interface, can now be loaded from any server module. You specify the module from which the interceptor should be loaded in the messaging-activemq subsystem of the server configuration file.

Exemplo de configuração de interceptor

<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.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>

4.8.5. Substituir as configuraões Netty Servlet

No JBoss EAP 6, você podia configurar um mecanismo servlet para trabalhar com o transporte Netty Servlet. No JBoss EAP 7, o ActiveMQ Artemis substituiu o HornetQ como o provedor de mensagem incorporado e esta configuração não está mais disponível. Você deve substituir a configuração do servlet para usar os novos conectores http de mensagem incorporados e aceitador http.

4.9. JMX Management Changes

The HornetQ component in JBoss EAP 6 provided its own JMX management; however, it was not recommended and is now deprecated and no longer supported. If you relied on this feature in JBoss EAP 6, you must migrate your management tooling to use either the JBoss EAP management CLI or the JMX management provided with JBoss EAP 7.

You must also upgrade your client libraries to use the jboss-client.jar that ships with JBoss EAP 7.

The following is an example of HornetQ JMX management code that was used in JBoss EAP 6.

JMXConnector connector = null;
try {
    HashMap environment = new HashMap();
    String[] credentials = new String[]{"admin", "Password123!"};
    environment.put(JMXConnector.CREDENTIALS, credentials);

    // HornetQ used the protocol "remoting-jmx" and port "9999"
    JMXServiceURL beanServerUrl = new JMXServiceURL("service:jmx:remoting-jmx://127.0.0.1:9999");

    connector = JMXConnectorFactory.connect(beanServerUrl, environment);
    MBeanServerConnection mbeanServer = connector.getMBeanServerConnection();

    // The JMX object name pointed to the HornetQ JMX management
    ObjectName objectName = new ObjectName("org.hornetq:type=Server,module=JMS");

    // The invoked method name was "listConnectionIDs"
    String[] connections = (String[]) mbeanServer.invoke(objectName, "listConnectionIDs", new Object[]{}, new String[]{});
    for (String connection : connections) {
        System.out.println(connection);
    }
} finally {
    if (connector != null) {
      connector.close();
   }
}

The following is an example of the equivalent code needed for ActiveMQ Artemis in JBoss EAP 7.

JMXConnector connector = null;
try {
    HashMap environment = new HashMap();
    String[] credentials = new String[]{"admin", "Password123!"};
    environment.put(JMXConnector.CREDENTIALS, credentials);

    // ActiveMQ Artemis uses the protocol "remote+http" and port "9990"
    JMXServiceURL beanServerUrl = new JMXServiceURL("service:jmx:remote+http://127.0.0.1:9990");

    connector = JMXConnectorFactory.connect(beanServerUrl, environment);
    MBeanServerConnection mbeanServer = connector.getMBeanServerConnection();

    // The JMX object name points to the new JMX management in the `messaging-activemq` subsystem
    ObjectName objectName = new ObjectName("jboss.as:subsystem=messaging-activemq,server=default");

    // The invoked method name is now "listConnectionIds"
    String[] connections = (String[]) mbeanServer.invoke(objectName, "listConnectionIds", new Object[]{}, new String[]{});
    for (String connection : connections) {
        System.out.println(connection);
    }
} finally {
    if (connector != null) {
      connector.close();
   }
}

Notice that the method names and parameters have changed in the new implementation. You can find the new method names in the JConsole by following these steps.

  1. Connect to the JConsole using the following command.

    EAP_HOME/bin/jconsole.sh
  2. Connect to JBoss EAP local process. Note that it should start with "jboss-modules.jar".
  3. In the MBeans tab, choose jboss.asmessaging-activemqdefaultOperations to display the list of method names and attributes.

4.10. Alterações de configurações de servidor ORB

A implementação do JacORB foi substituída com uma ramificação downstream do OpenJDK ORB no JBoss EAP 7.

O módulo de extensão org.jboss.as.jacorb, localizado em EAP_HOME/modules/system/layers/base/, foi substituído pelo módulo de extensão org.wildfly.iiop-openjdk.

O espaço de nomes da configuração do subsistema urn:jboss:domain:jacorb:1.4 no arquivo de configuração do servidor foi substituído pelo espaço de nome urn:jboss:domain:iiop-openjdk:1.0.

Segue um exemplo de configuração de sistema padrão jacorb em JBoss EAP 6.

<subsystem xmlns="urn:jboss:domain:jacorb:1.4">
    <orb socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
        <initializers security="identity" transactions="spec"/>
    </orb>
</subsystem>

Segue um exemplo de configuração de subsistema iiop-openjdk padrão no JBoss EAP 7.

<subsystem xmlns="urn:jboss:domain:iiop-openjdk:1.0">
    <orb socket-binding="jacorb" ssl-socket-binding="jacorb-ssl" />
    <initializers security="identity" transactions="spec" />
</subsystem>

A nova configuração de subsistema iiop-openjdk aceita somente um subconjunto de elementos legados e atributos. Segue um exemplo de configuração de subsistema jacorb na versão prévia do JBoss EAP que contém todos os elementos válidos e atributos:

<subsystem xmlns="urn:jboss:domain:jacorb:1.4">
   <orb name="JBoss" print-version="off" use-imr="off" use-bom="off"  cache-typecodes="off"
       cache-poa-names="off" giop-minor-version="2" socket-binding="jacorb" ssl-socket-binding="jacorb-ssl">
       <connection retries="5" retry-interval="500" client-timeout="0" server-timeout="0"
           max-server-connections="500" max-managed-buf-size="24" outbuf-size="2048"
           outbuf-cache-timeout="-1"/>
       <initializers security="off" transactions="spec"/>
   </orb>
   <poa monitoring="off" queue-wait="on" queue-min="10" queue-max="100">
       <request-processors pool-size="10" max-threads="32"/>
   </poa>
   <naming root-context="JBoss/Naming/root" export-corbaloc="on"/>
   <interop sun="on" comet="off" iona="off" chunk-custom-rmi-valuetypes="on"
       lax-boolean-encoding="off" indirection-encoding-disable="off" strict-check-on-tc-creation="off"/>
   <security support-ssl="off" add-component-via-interceptor="on" client-supports="MutualAuth"
       client-requires="None" server-supports="MutualAuth" server-requires="None"/>
   <properties>
       <property name="some_property" value="some_value"/>
   </properties>
</subsystem>

Os seguintes atributos de elementos não possuem mais suporte e devem ser removidos.

Tabela 4.4. Atributos para remover

ElementoAtributos sem suporte

<orb>

  • client-timeout
  • max-managed-buf-size
  • max-server-connections
  • outbuf-cache-timeout
  • outbuf-size
  • connection retries
  • retry-interval
  • name
  • server-timeout

<poa>

  • queue-min
  • queue-max
  • pool-size
  • max-threads

Os seguintes atributos on/off não possuem mais suporte e não serão migrados quando você executar a operação migrate da CLI de gerenciamento. Se eles estão definidos como on, você irá receber um alerta de migração. Outros atributos on/off que não foram mencionados nesta tabela, por exemplo, <security support-ssl="on|off">, ainda possuem suporte e serão migrados com êxito. A única diferença é que os valores serão alterados de on/off para true/false.

Tabela 4.5. Atributos para desativar ou remover

ElementoAtributos para serem definidos como desativados (off)

<orb>

  • cache-poa-names
  • cache-typecodes
  • print-version
  • use-bom
  • use-imr

<interop>

(todos exceto sun)

  • comet
  • iona
  • chunk-custom-rmi-valuetypes
  • indirection-encoding-disable
  • lax-boolean-encoding
  • strict-check-on-tc-creation

<poa/>

  • monitoring
  • queue-wait

4.11. Migrar a configuração de subsistema de threads

A configuração de servidor do JBoss EAP 6 incluía um subsistema threads que era utilizado para gerenciar grupos de thread em vários subsistemas no servidor.

O subsistema threads não está mais disponível no JBoss EAP 7. Como alternativa, cada subsistema é responsável por gerenciar seus próprios grupos de thread.

For information about how to configure thread pools for the infinispan subsystem, see Configure Infinispan Thread Pools in the JBoss EAP Configuration Guide.

For information about how to configure thread pools for the jgroups subsystem, see Configure JGroups Thread Pools in the JBoss EAP Configuration Guide.

In JBoss EAP 6, you configured thread pools for connectors and listeners for the web subsystem by referencing an executor that was defined in the threads subsystem. In JBoss EAP 7, you now configure thread pools for the undertow subsystem by referencing a worker that is defined in the io subsystem. For more information, see Configuring the IO Subsystem in the JBoss EAP Configuration Guide.

For information about about changes to thread pool configuration in the remoting subsystem, see Migrate the Remoting Subsystem Configuration in this guide, and Configuring the Endpoint in the JBoss EAP Configuration Guide.

4.12. Migrar a configuração de subsistema Remoto

No JBoss EAP 6, você configura o agrupamento de thread para o subsistema remoting ao determinar vários atributos worker-*. O agrupamento de thread de worker não é mais configurado no subsistema remoting no JBoss EAP 7 e caso você tentar modificar a configuração existente, você virá a seguinte mensagem.

WFLYRMT0022: Configuração worker não é mais utilizada, por favor, use configuração endpoint worker

No JBoss EAP 7, o worker thread pool é substituído por uma configuração de ponto de extremidade que referencia um subsistema worker definido no subsistema io.

For information about how to configure the endpoint, see Configuring the Endpoint in the JBoss EAP Configuration Guide.

4.13. Alterações de configurações de servidor WebSocket

Para utilizar WebSockets no JBoss EAP 6, você tinha que habilitar o protocolo conector Java NIO2 não bloqueante para conector http no subsistemaweb do arquivo de configuração do servidor JBoss EAP utilizando o comando similar ao que segue.

/subsystem=web/connector=http/:write-attribute(name=protocol,value=org.apache.coyote.http11.Http11NioProtocol)

Para utilizar WebSockets em um aplicativo, você tinha também que criar um elemento <enable-websockets> no arquivo WEB-INF/jboss-web.xml do aplicativo e defini-lo para true.

No JBoss EAP 7, você não precisa mais configurar o servidor para suporte WebSocket padrão ou configurar o aplicativo para utilizá-lo. WebSockets são exigências da especificação do Java EE 7 e os protocolos exigidos são configurados por padrão. Configurações de WebSocket mais complexas são feitas no servlet-container do subsistema undertow do arquivo de configuração do servidor JBoss EAP. Você pode ver as configurações disponíveis utilizando o seguinte comando.

/subsystem=undertow/servlet-container=default/setting=websockets:read-resource(recursive=true)
{
   "outcome" => "success",
   "result" => {
       "buffer-pool" => "default",
       "dispatch-to-worker" => true,
       "worker" => "default"
   }
}

Exemplos de códigos WebSocket também podem ser encontrados no início rápido (quickstarts) que é fornecido com JBoss EAP.

4.14. Alterações do servidor Single Sign-on

The infinispan subsystem still provides distributed caching support for HA services in the form of Infinispan caches in JBoss EAP 7; however the caching and distribution of authentication information is handled differently than in previous releases.

No JBoss EAP 6, se o single sign-on (SSO) não foi fornecido um cache Infinispan, o cache não era distribuído.

No JBoss EAP 7, SSO é distribuído automaticamente quando você seleciona o perfil HA. Quando executar com o perfil HA, cada host tem seu próprio cache Infinispan, que é baseado no cache padrão do contêiner de cache da web. Este cache armazena sessões relevantes e informações de cookie SSO para o host. JBoss EAP trata a propagação de informação de cache individual para todos os hosts. Não existe nenhuma maneira para atribuir especificamente um cache Infinispan para um SSO no JBoss EAP 7.

No JBoss EAP 7, o SSO é configurado no subsistema undertowdo arquivo de configuração do servidor.

Não há exigência de alteração de código de aplicativos para SSO quando migrando para JBoss EAP 7.

4.15. Alterações na configuração da fonte de dados

4.15.1. Nome de driver da fonte de dados JBDC

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

Driver contendo uma classe única

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

Driver contendo classes múltiplas

No JBoss EAP 6, se houvesse mais de uma classe listada no arquivo META-INF/services/java.sql.Driver, você especificaria qual classe seria a classe do driver ao acrescentar seu nome ao nome de JAR, junto com as versões menores e maiores, 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
Nota

Um traço sublinhado foi adicionado entre o JAR_NAME e o DRIVER_CLASS_NAME.

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

Exemplo de nome de driver no JBoss EAP 6

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

Exemplo de nome de driver no JBoss EAP 7

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

4.16. Alterações de configurações de servidor de segurança

For information about Java Security Manager server configuration changes, see Considerations Moving from Previous Versions in How To Configure Server Security for JBoss EAP.

4.17. Alterações do subsistema de transações

Alguns atributos de configuração do gerenciamento de transações que estavam disponíveis no subsistema transactions no JBoss EAP 6 foram alterados no JBoss EAP 7.

Removed Transactions Subsystem Attributes

A seguinte tabela lista os atributos do JBoss EAP 6 que foram removidos do subsistema transactions no JBoss EAP 7 e os atributos substituídos correspondentes.

Atributo no JBoss EAP 6Substituto no JBoss EAP 7

path

object-store-path

relative-to

object-store-relative-to

Atributos de subsistema de transações preteridos

The following attributes that were available in the transactions subsystem in JBoss EAP 6 are deprecated in JBoss EAP 7. The deprecated attributes might be removed in a future release of the product. The following table lists the equivalent replacement attributes.

Atributo no JBoss EAP 6Substituto no JBoss EAP 7

use-hornetq-store

use-journal-store

hornetq-store-enable-async-io-to

journal-store-enable-async-io

enable-statistics

statistics-enabled

4.18. Changes to mod_cluster Configuration

A configuração para listas de proxy estáticas em mod_cluster foi alterada no JBoss EAP 7.

No JBoss EAP 6, você configurava o atributo proxy-list, que era um lista separada por vírgula de endereços proxy httpd especificados no formato de hostname:port.

O atributo proxy-list é preterido no JBoss EAP 7. Ele foi substituído pelo atributo proxies, que é uma lista de nomes de associação de soquetes de saída.

This change impacts how you define a static proxy list, for example, when disabling advertising for mod_cluster. For information about how to disable advertising for mod_cluster, see Disable Advertising for mod_cluster in the JBoss EAP Configuration Guide.

For more information about mod_cluster attributes, see ModCluster Subsystem Attributes in the JBoss EAP Configuration Guide.