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

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.

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>

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.

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

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

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.

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

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

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>

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.

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.

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.

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.

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.

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.

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.

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:import-journal(file=OUTPUT_DIRECTORY/OldMessagingData.xml)

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>

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.

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

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.

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

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.

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