Capítulo 4. Cambios de configuración del servidor [Esto es una traducción automática]

Los mensajes de registro están prefijados con el código de proyecto para el subsistema que informa el mensaje. Los prefijos de todos los mensajes de registro han cambiado en JBoss EAP 7.

Para obtener una lista completa de los nuevos prefijos de código de proyecto de mensaje de registro utilizados en JBoss EAP 7, consulte Códigos de proyecto utilizados en JBoss EAP en el JBoss EAP Guía de desarrollo.

El registrador de raíz JBoss EAP 7.0 incluía un controlador de registro de consola para todos los perfiles de servidor de dominio y para todos los perfiles independientes predeterminados, excepto el standalone-full-ha perfil. El registrador de raíz JBoss EAP 7.1 ya no incluye un controlador de registro de consola para los perfiles de dominio administrado. El controlador de host y el controlador de proceso se conectan a la consola de forma predeterminada. Para lograr la misma funcionalidad que se proporcionó en JBoss EAP 7.0, consulte Configurar un controlador de registro de consola en el Guía de configuración para JBoss EAP.

Undertow reemplaza a JBoss Web como el servidor web en JBoss EAP 7. Esto significa que el legado web la configuración del subsistema debe migrarse al nuevo JBoss EAP 7 undertow configuración del subsistema

Puede usar la CLI de administración migrate operación para migrar el web subsistema a undertow en el archivo de configuración del servidor. Sin embargo, tenga en cuenta que esta operación no puede migrar todas las configuraciones del subsistema web de JBoss. Si ve entradas de "advertencia de migración", debe ejecutar comandos de CLI de administración adicionales para migrar esas configuraciones a Undertow. Para obtener más información acerca de la CLI de administración migrate operación, ver Gestión de la migración de la CLI Operación.

El siguiente es un ejemplo de lo predeterminado web Configuración del subsistema en 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>

El siguiente es un ejemplo de lo predeterminado undertow configuración del subsistema en 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>

La CLI de gestión migrate la operación no puede migrar automáticamente las condiciones de reescritura. Se informan como "advertencias de migración" y debe migrarlas manualmente. Puede crear la configuración equivalente en JBoss EAP 7 utilizando Undertow predice los atributos y manipuladores.

El siguiente es un ejemplo de web configuración del subsistema en JBoss EAP 6 que incluye rewrite configuración.

<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 el Gestión de la migración de la CLI Operación instrucciones para iniciar su servidor y la CLI de administración, luego migre el web archivo de configuración del subsistema usando el siguiente comando.

/subsystem=web:migrate

Las siguientes "advertencias de migración" se informan cuando ejecuta el migrate operación en la configuración anterior.

/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 el archivo de configuración del servidor y verá la siguiente configuración para 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 la CLI de administración para crear el filtro para reemplazar la configuración de reescritura en el undertow subsistema. Debería ver "{" resultado "⇒" 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

Revise el archivo de configuración del servidor actualizado. El subsistema web JBoss ahora se migró completamente y se configuró en 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 obtener más información acerca de cómo configurar filtros y controladores mediante CLI de administración, consulte Configurar el servidor web en el JBoss EAP 7 Guía de configuración.

En el lanzamiento anterior de JBoss EAP, las propiedades del sistema se podían usar para modificar el comportamiento predeterminado de JBoss Web. Para obtener información sobre cómo configurar el mismo comportamiento en Undertow, consulte Referencia de migración de propiedades del sistema web JBoss

Cuando migra de JBoss EAP 6.4 a JBoss EAP 7.1, puede encontrar que los registros de acceso ya no escriben los valores esperados de "Referer" y "User-agent". Esto se debe a que JBoss Web, que se incluyó en JBoss EAP 6.4, utilizó un patrón de %{headername}i en el access-log para registrar un encabezado entrante.

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

Con el cambio para usar Undertow en JBoss EAP 7.1, el patrón para un encabezado entrante ha cambiado a %{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;"/>

Versiones anteriores de válvulas compatibles con JBoss EAP. Las válvulas son clases personalizadas insertadas en la interconexión de procesamiento de solicitudes para una aplicación antes de filtros de servlets para realizar cambios en la solicitud o realizar un procesamiento adicional.

Esta sección describe cómo migrar las válvulas globales. La migración de válvulas personalizadas y autenticadoras están cubiertas en Migrar válvulas de aplicaciones personalizadas sección de esta guía.

Undertow, que reemplaza a JBoss Web en JBoss EAP 7, no admite válvulas globales; sin embargo, debe poder lograr una funcionalidad similar mediante el uso de controladores Undertow. Undertow incluye una serie de controladores incorporados que proporcionan una funcionalidad común. También proporciona la capacidad de crear controladores personalizados, que se pueden usar para reemplazar la funcionalidad de válvula personalizada.

Si su aplicación usa válvulas, debe reemplazarlas con el código del controlador Undertow apropiado para lograr la misma funcionalidad cuando migre a JBoss EAP 7.

Para obtener más información sobre cómo configurar controladores, consulte Configurando Manejadores en el JBoss EAP 7 Guía de configuración.

Para obtener más información acerca de cómo configurar filtros, consulte Configurar filtros en el JBoss EAP 7 Guía de configuración.

Migrar válvulas globales [Esto es una traducción automática]

La siguiente tabla enumera las válvulas proporcionadas por JBoss Web en la versión anterior de JBoss EAP y el correspondiente controlador integrado de Undertow. Las válvulas JBoss Web están ubicadas en el org.apache.catalina.valves paquete.

Puede usar la CLI de administración migrate operación para migrar automáticamente válvulas globales que cumplan los siguientes criterios:

Para obtener más información acerca de la CLI de administración migrate operación, ver Gestión de la migración de la CLI Operación.

JDBCAccessLogValve Procedimiento de migración manual

los org.apache.catalina.valves.JDBCAccessLogValve la válvula es una excepción a la regla y no se puede migrar automáticamente a io.undertow.server.handlers.JDBCLogHandler. Siga los pasos a continuación para migrar la siguiente válvula de ejemplo.

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

Especificaciones anteriores para Set-Cookie La sintaxis del encabezado de respuesta HTTP, por ejemplo RFC2109 y RFC2965, permitía espacios en blanco y otros caracteres separadores en el valor de la cookie cuando se citaba el valor de la cookie. JBoss Web en JBoss EAP 6.4 cumplió con las especificaciones anteriores y citó automáticamente un valor de cookie cuando contenía cualquier carácter separador.

los RFC6265 especificación para Set-Cookie La sintaxis del encabezado de respuesta HTTP indica que los valores de las cookies en el Set-Cookie El encabezado de respuesta debe ajustarse a las restricciones de gramática específicas. Por ejemplo, deben ser caracteres US-ASCII, pero no pueden incluir CTRL (controles), espacios en blanco, comillas dobles, comas, puntos y comas o caracteres de barra diagonal inversa.

En JBoss EAP 7.0, antes del parche acumulativo Red Hat JBoss Enterprise Application Platform 7.0 Actualización 08, Undertow no restringe estos caracteres no válidos y no cita las cookies que contenían los caracteres excluidos. Si aplica este parche acumulativo o un parche acumulativo más reciente, puede habilitar la validación de cookies conforme con RFC6265 configurando el io.undertow.cookie.DEFAULT_ENABLE_RFC6265_COOKIE_VALIDATION propiedad del sistema a true.

En JBoss EAP 7.1, de forma predeterminada, Undertow no habilita la validación de cookies conforme con RFC6265. Cita cookies que contienen los caracteres excluidos. En JBoss EAP 7.1, no puede usar el io.undertow.cookie.DEFAULT_ENABLE_RFC6265_COOKIE_VALIDATION propiedad del sistema para habilitar la validación de cookies conforme con RFC6265. En su lugar, habilita la validación de cookies conforme a RFC6265 para un oyente HTTP, HTTPS o AJP configurando el rfc6265-cookie-validation atributo del oyente a true. El valor predeterminado para este atributo es false. El siguiente ejemplo habilita la validación de cookies compatibles con RFC6265 para el escucha HTTP.

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

JBoss EAP 6.4, que incluía JBoss Web como servidor web, permitió HTTP TRACE método llamadas por defecto.

Undertow, que reemplaza a JBoss Web como servidor web en JBoss EAP 7, no permite HTTP TRACE método llamadas por defecto. Esta configuración se configura usando el disallowed-methods atributo de la http-listener elemento en el undertow subsistema. Esto se puede confirmar revisando el resultado de la siguiente read-resource mando. Tenga en cuenta que el valor para el disallowed-methods atributo es ["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 habilitar HTTP TRACE llamadas de método en JBoss EAP 7 y posteriores, debe eliminar la entrada "TRACE" del disallowed-methods lista de atributos ejecutando el siguiente comando.

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

Cuando ejecutas el read-resource comando nuevamente, notará el TRACE la llamada al método ya no se encuentra en la lista de métodos no 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 obtener más información sobre el comportamiento predeterminado de los métodos HTTP, consulte Comportamiento predeterminado de los métodos HTTP en el JBoss EAP Guía de configuración.

En JBoss EAP 7.0, el contexto raíz de una aplicación web estaba deshabilitado por defecto en mod_cluster.

Este ya no es el caso en JBoss EAP 7.1. Esto puede tener consecuencias inesperadas si espera que el contexto raíz esté deshabilitado. Por ejemplo, las solicitudes pueden encaminarse erróneamente a nodos no deseados o una aplicación privada que no debe estar expuesta puede ser accesible inadvertidamente a través de un proxy público. Las ubicaciones de retroceso también ahora están registradas con el equilibrador de carga mod_cluster automáticamente a menos que estén explícitamente excluidas.

Use el siguiente comando CLI de administración para excluir ROOT del modcluster configuración del subsistema

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

Utilice el siguiente comando CLI de administración para deshabilitar la aplicación web de bienvenida predeterminada.

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

Para obtener más información sobre cómo configurar la aplicación web de bienvenida predeterminada, consulte Configurar la aplicación web de bienvenida predeterminada en el Guía de desarrollo para JBoss EAP.

En la configuración predeterminada de JBoss EAP 6, JGroups utilizó el public interfaz definida en el <interfaces> sección del archivo de configuración del servidor.

Debido a que es una práctica recomendada utilizar una interfaz de red dedicada, JGroups ahora usa por defecto el nuevo private interfaz que se define en el <interfaces> sección del archivo de configuración del servidor en JBoss EAP 7.

JGroups proporciona soporte de comunicación grupal para servicios de HA en forma de canales de JGroups. JBoss EAP 7 presenta <channel> elementos a la jgroups subsistema en el archivo de configuración del servidor. Puede agregar, eliminar o cambiar la configuración de los canales de JGroups utilizando la CLI de administración.

Para obtener más información acerca de cómo configurar JGroups, consulte Comunicación de clúster con JGroups en el JBoss EAP Guía de configuración.

En JBoss EAP 6, los cachés agrupados por defecto para la replicación de sesión web y la replicación EJB se replicaron ASYNC cachés Esto ha cambiado en JBoss EAP 7. Los cachés agrupados por defecto están ahora distribuidos ASYNC cachés Los cachés replicados ya no están configurados de manera predeterminada. Ver Configurar el modo de caché en el JBoss EAP Guía de configuración para obtener información acerca de cómo agregar un caché replicado y hacerlo predeterminado.

Esto solo lo afecta cuando usa la nueva configuración predeterminada de JBoss EAP 7. Si migra la configuración de JBoss EAP 6, la configuración de infinispan subsistema será preservado.

El comportamiento de ASYNC la estrategia de caché ha cambiado en JBoss EAP 7.

En JBoss EAP 6, ASYNC las lecturas de caché estaban libres de bloqueo. Aunque nunca bloquearían, eran propensos a lecturas sucias de datos obsoletos, por ejemplo, en la conmutación por error. Esto se debe a que permitiría que las solicitudes posteriores para el mismo usuario se inicien antes de que se complete la solicitud anterior. Esta permisividad no es aceptable cuando se utiliza el modo distribuido, ya que los cambios en la topología del clúster pueden afectar la afinidad de la sesión y dar como resultado fácilmente datos obsoletos.

En JBoss EAP 7, ASYNC las lecturas de caché requieren bloqueos. Como ahora bloquean nuevas solicitudes del mismo usuario hasta que finaliza la replicación anterior, se evitan las lecturas sucias.

Tenga en cuenta las siguientes restricciones al configurar una memoria caché de sesión de estado con estado personalizado (SFSB) para la pasivación en JBoss EAP 7.1.

Un cambio en el comportamiento entre JBoss EAP 7.0 y JBoss EAP 7.1 requiere que cualquier actualización del protocolo de transporte del contenedor de caché se realice en modo batch o utilizando un encabezado especial. Este cambio en el comportamiento también afecta las herramientas que se utilizan para administrar el servidor JBoss EAP.

El siguiente es un ejemplo de los comandos CLI de gestión utilizados para configurar el protocolo de transporte de contenedor de caché en 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)

El siguiente es un ejemplo de los comandos CLI de administración necesarios para realizar la misma configuración en JBoss EAP 7.1. Tenga en cuenta que los comandos se ejecutan en modo por lotes.

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

Si prefiere no usar el modo por lotes, puede especificar el encabezado de operación allow-resource-service-restart=true al definir el transporte. Tenga en cuenta que esto reinicia el servicio para que las operaciones surtan efecto y algunos servicios pueden dejar de funcionar hasta que se reinicie el servicio.

Si usa scripts para actualizar el protocolo de transporte del contenedor de caché, asegúrese de revisarlos y agregar el modo por lotes.

los org.jboss.as.messaging módulo de extensión, ubicado en EAP_HOME/modules/system/layers/base/, ha sido reemplazado por org.wildfly.extension.messaging-activemq módulo de extensión.

los urn:jboss:domain:messaging:3.0 El espacio de nombre de configuración del subsistema ha sido reemplazado por urn:jboss:domain:messaging-activemq:2.0 espacio de nombres

Cambios en la administración de JMX [Esto es una traducción automática]

En la mayoría de los casos, se hizo un esfuerzo para mantener los nombres de elementos y atributos lo más similares posibles a los utilizados en lanzamientos anteriores. La siguiente tabla enumera algunos de los cambios.

Las operaciones de gestión invocadas en el nuevo messaging-activemq subsistema ha cambiado desde /subsystem=messaging/hornetq-server= a /subsystem=messaging-activemq/server=.

Puede migrar un JBoss EAP existente 6 messaging configuración del subsistema a messaging-activemq subsistema en un servidor JBoss EAP 7 invocando su migrate operación.

/subsystem=messaging:migrate

Antes de ejecutar el migrate operación, puede invocar el describe-migration operación para revisar la lista de operaciones de administración que se realizarán para migrar del JBoss EAP existente 6 messaging configuración del subsistema a messaging-activemq subsistema en el servidor JBoss EAP 7.

/subsystem=messaging:describe-migration

los migrate y describe-migration las operaciones también muestran una lista de migration-warnings para recursos o atributos que no se pueden migrar automáticamente.

Advertencias de la operación de migración del subsistema de mensajería [Esto es una traducción automática]

los describe-migration y migrate operaciones para el messaging subsistema proporciona un argumento de configuración adicional. Si desea configurar la mensajería para permitir que los clientes heredados de JBoss EAP 6 se conecten al servidor JBoss EAP 7, puede agregar la booleana add-legacy-entries argumento a la describe-migration o migrate operación de la siguiente manera.

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

Si el argumento booleano add-legacy-entries se establece en true, el messaging-activemq subsistema crea el legacy-connection-factory recurso y agrega legacy-entries al jms-queue y jms-topic recursos.

Si el argumento booleano add-legacy-entries se establece en false, no se crean recursos heredados en messaging-activemq el subsistema y los clientes JMS heredados no podrán comunicarse con los servidores JBoss EAP 7. Este es el valor predeterminado.

Para obtener más información sobre la compatibilidad directa e inversa, consulte la Compatibilidad hacia atrás y adelante en Configurando la Mensajería para JBoss EAP.

Para obtener más información acerca de la CLI de administración migrate y describe-migration operaciones, ver Gestión de la migración de la CLI Operación.

Cambio en el comportamiento del atributo forward-when-no-consumers

El comportamiento de forward-when-no-consumers atributo ha cambiado en JBoss EAP 7.

En JBoss EAP 6, cuando forward-when-no-consumers fue configurado para false y no había consumidores en un clúster, los mensajes se redistribuyeron a todos los nodos de un clúster.

Este comportamiento ha cambiado en JBoss EAP 7. Cuando forward-when-no-consumers se establece en false y no hay consumidores en un clúster, los mensajes no se redistribuyen. En cambio, se mantienen en el nodo original al que se enviaron.

Cambio en la política de equilibrio de carga del clúster predeterminado

La política de equilibrio de carga del clúster predeterminada ha cambiado en JBoss EAP 7.

En JBoss EAP 6, la política de equilibrio de carga del clúster por defecto era similar a STRICT, que es como establecer el legado forward-when-no-consumers parámetro a true. En JBoss EAP 7, el valor predeterminado es ahora ON_DEMAND, que es como establecer el legado forward-when-no-consumers parámetro a false. Para obtener más información acerca de estas configuraciones, consulte Atributos de conexión de clúster en Configurando la Mensajería para JBoss EAP.

Cambios en la configuración del servidor del subsistema de mensajería [Esto es una traducción automática]

La configuración XML ha cambiado significativamente con el nuevo messaging-activemq subsistema, y ​​ahora proporciona un esquema XML más consistente con otros subsistemas JBoss EAP.

Se recomienda encarecidamente que no intente modificar JBoss EAP messaging configuración XML del subsistema para ajustarse a la nueva messaging-activemq subsistema. En cambio, invoque el subsistema heredado migrate operación. Esta operación escribirá la configuración XML del nuevo messaging-activemq subsistema como parte de su ejecución.

Puede usar uno de los siguientes enfoques para migrar los datos de mensajería de una versión anterior a la versión actual de JBoss EAP.

Debido al cambio de HornetQ a ActiveMQ Artemis como proveedor de soporte JMS, tanto el formato como la ubicación de los datos de mensajería cambiaron en JBoss EAP 7.0 y posterior. Ver Asignación de nombres de carpeta de mensajería para detalles de los cambios en los nombres y ubicaciones de las carpetas de datos de mensajería entre las versiones 6.4 y 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

En versiones anteriores de JBoss EAP, las colas de destino JMS se configuraban en <jms-destinations> elemento bajo el <hornetq-server> elemento en el 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>

En JBoss EAP 7, la cola de destino JMS está configurada de manera predeterminada <server> elemento de la messaging-activemq subsistema.

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

Los interceptores de mensajería han cambiado significativamente en JBoss EAP 7 con el reemplazo de HornetQ por ActiveMQ Artemis como proveedor de mensajería JMS.

El HornetQ messaging El subsistema incluido en la versión anterior de JBoss EAP requiere que instales los interceptores HornetQ agregándolos a un JAR y luego modificando el HornetQ module.xml archivo.

los messaging-activemq subsistema incluido en JBoss EAP 7 no requiere la modificación de un module.xml archivo. Clases de interceptor de usuario, que ahora implementan Apache ActiveMQ Artemis Interceptador interfaz, ahora se puede cargar desde cualquier módulo de servidor. Usted especifica el módulo desde el cual se debe cargar el interceptor en el messaging-activemq subsistema del archivo de configuración del 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>

En JBoss EAP 6, puede configurar un motor de servlet para que funcione con el transporte de Netty Servlet. Debido a que ActiveMQ Artemis reemplaza a HornetQ como el proveedor de mensajería incorporado en JBoss EAP 7, esta configuración ya no está disponible. En su lugar, debe reemplazar la configuración de servlet para usar los nuevos conectores de mensajería HTTP incorporados y los aceptores HTTP.

La forma en que configura un adaptador de recursos JMS genérico para usar con un proveedor JMS de terceros ha cambiado en JBoss EAP 7. Para obtener más información, consulte Implementación de un adaptador de recursos JMS genérico en Configurando la Mensajería para JBoss EAP.

En JBoss EAP 7.0, si configuró el replication-master política sin especificar el check-for-live-server atributo, su valor predeterminado era false. Esto ha cambiado en JBoss EAP 7.1. El valor predeterminado para el check-for-live-server atributo es ahora true.

El siguiente es un ejemplo de un comando CLI de administración que configura el replication-master política sin especificar el check-for-live-server atributo.

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

Cuando lea el recurso utilizando la CLI de administración, tenga en cuenta que check-for-live-server el valor de atributo está configurado para 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"}
}

los serialVersionUID de javax.jms.JMSException cambiado entre JMS 1.1 y JMS 2.0.0. Esto significa que si una instancia de JMSException, o cualquiera de sus subclases, se serializa usando JMS 1.1, no se puede deserializar usando JMS 2.0.0. Lo contrario también es cierto. Si una instancia de JMSException se serializa usando JMS 2.0.0, no se puede deserializar usando JMS 1.1. En ambos casos, arroja una excepción similar a la siguiente:

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

Este problema se corrigió en la versión de mantenimiento JMS 2.0.1.

Implementación de JMS para cada versión de JBoss EAP [Esto es una traducción automática]

Tenga en cuenta que serialVersionUID la incompatibilidad puede generar un problema de migración en las siguientes situaciones:

Tenga en cuenta que si envía un mensaje que contiene un JMSException utilizando un cliente JBoss EAP 6.4, migre sus datos de mensajería a JBoss EAP 7.1, y luego intente deserializar ese mensaje utilizando un cliente JBoss EAP 7.1, la deserialización tendrá éxito porque la serialVersionUID en JMS 1.1 es compatible con el de JMS 2.0.1.

Cuando configuró un origen de datos en la versión anterior de JBoss EAP, el valor especificado para el nombre del controlador depende de la cantidad de clases enumeradas en el META-INF/services/java.sql.Driver archivo contenido en el controlador JDBC JAR.

Controlador que contiene una clase individual

Si el META-INF/services/java.sql.Driver el archivo especificó solo una clase, el valor del nombre del controlador era simplemente el nombre del JAR del controlador JDBC. Esto no ha cambiado en JBoss EAP 7.

Conductor que contiene múltiples clases

En JBoss EAP 6, si había más de una clase enumerada en META-INF/services/java.sql.Driver archivo, especificó qué clase era la clase de controlador al agregar su nombre al nombre JAR, junto con la versión principal y secundaria, en el siguiente formato.

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

En JBoss EAP 7, esto ha cambiado. Ahora especifica el nombre del controlador usando el siguiente formato.

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

El controlador JDBC de MySQL 5.1.31 es un ejemplo de un controlador que contiene dos clases. El nombre de la clase del controlador es com.mysql.jdbc.Driver. Los siguientes ejemplos demuestran las diferencias entre cómo se especifica el nombre del controlador en la versión anterior y actual de 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

Cambios en el comportamiento de seguridad heredado entre JBoss EAP 7.0 y JBoss EAP 7.1 [Esto es una traducción automática]

Al utilizar dominios de seguridad heredados, JBoss EAP 7.1 proporciona la generación automática de un certificado autofirmado para fines de desarrollo. Esta característica, que no estaba disponible en JBoss EAP 7.0, está habilitada de manera predeterminada. Esto significa que si está ejecutando en modo FIPS, debe configurar el servidor para deshabilitar la creación automática de certificados autofirmados. De lo contrario, es posible que vea el siguiente error al iniciar el 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 obtener información sobre la creación automática de certificados autofirmados, consulte Creación automática de certificados autofirmados para aplicaciones en Cómo configurar la seguridad del servidor para JBoss EAP.