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.

La API de Java para RPC basado en XML (JAX-RPC) fue desaprobada en Java EE 6 y es opcional en Java EE 7. Ya no está disponible o no es compatible con JBoss EAP 7. Las aplicaciones que usan JAX-RPC deben migrarse para usar JAX-WS, que es el marco actual de servicios web estándar de Java EE.

El uso de los servicios web JAX-RPC se puede identificar de cualquiera de las siguientes maneras:

En lanzamientos anteriores de JBoss EAP, podía personalizar la integración de JBossWS y Apache CXF incluyendo un jbossws-cxf.xml archivo de configuración con el archivo de implementación de punto final. Un caso de uso para esto fue configurar cadenas de interceptor para clientes del servicio web y puntos finales del servidor en el bus Apache CXF. Esta integración requirió que Spring se implementara en el servidor JBoss EAP.

La integración de Spring ya no es compatible con JBoss EAP 7. Cualquier aplicación que contenga un jbossws-cxf.xml El archivo de configuración del descriptor debe modificarse para reemplazar la configuración personalizada definida en ese archivo. Si bien aún es posible acceder directamente a la API de Apache CXF, tenga en cuenta que la aplicación no será portátil.

El enfoque sugerido es reemplazar las configuraciones personalizadas de Spring con las nuevas opciones de configuración del descriptor JBossWS siempre que sea posible. El enfoque basado en el descriptor JBossWS proporciona una funcionalidad similar sin requerir la modificación del código del punto final del cliente. En algunos casos, puede reemplazar Spring con Context Dependency Injection (CDI).

Migrar interceptores de mensajería [Esto es una traducción automática]

El descriptor JBossWS proporciona nuevas opciones de configuración que le permiten declarar los interceptores sin modificar el código de punto final del cliente. En su lugar, declara los interceptores dentro de las configuraciones predefinidas de cliente y punto final al especificar una lista de nombres de clase de interceptor para el cxf.interceptors.in y cxf.interceptors.out propiedades.

El siguiente es un ejemplo de jaxws-endpoint-config.xml archivo que declara interceptores usando estas propiedades.

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointImpl</config-name>
    <property>
      <property-name>cxf.interceptors.in</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointInterceptor,org.jboss.test.ws.jaxws.cxf.interceptors.FooInterceptor</property-value>
    </property>
    <property>
      <property-name>cxf.interceptors.out</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointCounterInterceptor</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

Características de Apache CXF

El descriptor JBossWS le permite declarar características dentro de las configuraciones predefinidas de cliente y punto final al especificar una lista de nombres de clase de entidad para el cxf.features propiedad.

El siguiente es un ejemplo de jaxws-endpoint-config.xml archivo que declara una característica que usa esta propiedad.

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>Custom FI Config</config-name>
    <property>
      <property-name>cxf.features</property-name>
      <property-value>org.apache.cxf.feature.FastInfosetFeature</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

Transporte HTTP Apache CXF

En Apache CXF, la configuración de transporte HTTP se logra especificando org.apache.cxf.transport.http.HTTPConduit opciones. La integración de JBossWS permite que los conductos se modifiquen mediante programación utilizando la API de Apache CXF de la siguiente manera.

import org.apache.cxf.frontend.ClientProxy;
import org.apache.cxf.transport.http.HTTPConduit;
import org.apache.cxf.transports.http.configuration.HTTPClientPolicy;

// Set chunking threshold before using a JAX-WS port client
...
HTTPConduit conduit = (HTTPConduit)ClientProxy.getClient(port).getConduit();
HTTPClientPolicy client = conduit.getClient();

client.setChunkingThreshold(8192);
...

También puede controlar y anular el Apache CXF HTTPConduit valores predeterminados al establecer las propiedades del sistema.

los cxf-api y cxf-rt-core Los JAR se han fusionado en uno cxf-core TARRO. Como consecuencia, el org.apache.cxf módulo en JBoss EAP ahora contiene el cxf-core JAR y expone más clases que en la versión anterior.

Si desea utilizar el cifrado AES con el modo Galois / Counter (GCM) para el cifrado simétrico en XML / WS-Security, necesita el proveedor de seguridad BouncyCastle.

JBoss EAP 7 se envía con el org.bouncycastle módulo y JBossWS ahora puede confiar en su cargador de clases para obtener y usar el proveedor de seguridad BouncyCastle. Por lo tanto, ya no es necesario instalar estáticamente BouncyCastle en la JVM actual. Para aplicaciones que se ejecutan fuera del contenedor, el proveedor de seguridad puede estar disponible para JBossWS agregando una biblioteca BouncyCastle a la ruta de clase.

Puede deshabilitar este comportamiento configurando org.jboss.ws.cxf.noLocalBC valor de propiedad para true en el jaxws-endpoint-config.xml archivo descriptor de despliegue para el servidor o el jaxws-client-config.xml archivo descriptor para clientes.

Si desea utilizar una versión diferente a la que se envía con JBoss EAP, aún puede instalar BouncyCastle estáticamente en la JVM. En ese caso, el proveedor de seguridad BouncyCastle instalado de forma estática se elige sobre el proveedor presente en la ruta de clase. Para evitar cualquier problema, debe usar BouncyCastle 1.49, 1.51 o superior.

La estrategia de selección de bus predeterminada para los clientes que se ejecutan en el contenedor ha cambiado desde THREAD_BUS a TCCL_BUS. Para los clientes que se quedan sin contenedor, la estrategia predeterminada sigue siendo THREAD_BUS. Puede restablecer el comportamiento al de la versión anterior mediante uno de los siguientes métodos.

Los contenedores deben usar los constructores de estilo JAX-WS 2.2, que incluyen WebServiceFeature clase como argumento en el constructor, para construir clientes que se inyectan en las referencias del servicio web. JBoss EAP 6.4, que se envía con JBossWS 4, oculta ese requisito. JBoss EAP 7 se envía con JBossWS 5, que ya no oculta este requisito. Esto significa que las clases de servicio proporcionadas por el usuario deben implementar JAX-WS 2.2 o posterior al actualizar el código existente para usar el javax.xml.ws.Service constructor que incluye uno o más WebServiceFeature argumentos.

protected Service(URL wsdlDocumentLocation,
       QName serviceName,
       WebServiceFeature... features)

En versiones anteriores, podía deshabilitar la comprobación del nombre de host de HTTPS URL con el nombre común (CN) de un servicio que figura en su certificado estableciendo la propiedad del sistema. org.jboss.security.ignoreHttpsHost a true. Este nombre de propiedad del sistema ha sido reemplazado por cxf.tls-client.disableCNCheck.

Como consecuencia de habilitar las inyecciones en los puntos finales del servicio y los controladores del cliente del servicio, ya no es posible cargar automáticamente clases de controladores desde el org.jboss.as.webservices.server.integration Módulo JBoss. Si su aplicación depende de una configuración predefinida determinada, es posible que deba definir de forma explícita nuevas dependencias de módulos para su implementación. Para más información, ver Migrar dependencias de módulos explícitos

los Mecanismo de invalidación de estándares endosados ​​por Java se desaprobó en JDK 1.8_40 con la intención de eliminarlo en JDK 9. Este mecanismo permitió a los desarrolladores hacer que las bibliotecas estuvieran disponibles para todas las aplicaciones desplegadas colocando los JAR en un directorio endosado dentro del JRE.

Si su aplicación utiliza la implementación JBossWS de Apache CXF, JBoss EAP 7 garantiza que las dependencias requeridas se agreguen en el orden correcto y usted no debería verse afectado por este cambio. Si su aplicación accede a Apache CXF directamente, ahora debe proporcionar las dependencias de Apache CXF después de las dependencias de JBossWS como parte de la implementación de su aplicación.

En versiones anteriores de JBoss EAP, puede configurar el jboss-webservices.xml archivo descriptor de despliegue para implementaciones de servicios web EJB en el META-INF/ directorio de archivos JAR o en el WEB-INF/ directorio para las implementaciones del servicio web POJO y los puntos finales del servicio web EJB incluidos en los archivos WAR.

En JBoss EAP 7, ahora puede configurar el jboss-webservices.xml archivo de descriptor de despliegue en META-INF/ directorio de un archivo EAR. Si un jboss-webservices.xml archivo se encuentra tanto en el archivo EAR y el archivo JAR o WAR, los datos de configuración en el jboss-webservices.xml archivo para el JAR o WAR anula los datos correspondientes en el archivo de descriptor EAR.

Los archivos de descriptores de distribución de recursos HornetQ JMS patentados identificados por el patrón de nomenclatura -jms.xml ya no funciona en JBoss EAP 7. El siguiente es un ejemplo de un archivo de descriptor de implementación de recursos JMS en JBoss EAP 6.

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0">
  <hornetq-server>
    <jms-destinations>
      <jms-queue name="testQueue">
        <entry name="queue/test"/>
        <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <entry name="topic/test"/>
        <entry name="java:jboss/exported/jms/topic/test"/>
      </jms-topic>
    </jms-destinations>
  </hornetq-server>
</messaging-deployment>

Si usaste -jms.xml Los descriptores de implementación JMS en su aplicación en la versión anterior, puede convertir su aplicación para usar el descriptor de implementación estándar de Java EE 7 como se especifica en la sección EE.5.18 del Especificación Java EE 7 o puede actualizar el descriptor de implementación para usar messaging-activemq-deployment esquema en su lugar.

Si elige actualizar el descriptor, debe hacer las siguientes modificaciones.

El archivo modificado debería verse como el siguiente ejemplo.

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-activemq-deployment:1.0">
  <server>
    <jms-destinations>
      <jms-queue name="testQueue">
        <entry name="queue/test"/>
        <entry name="java:jboss/exported/jms/queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <entry name="topic/test"/>
        <entry name="java:jboss/exported/jms/topic/test"/>
      </jms-topic>
    </jms-destinations>
  </server>
</messaging-deployment>

Para obtener información sobre los cambios de configuración del servidor relacionados con la mensajería, consulte Cambios en la configuración del servidor de mensajería.

JBoss EAP 7 sigue siendo compatible con la API JMS 1.1, por lo que no necesita modificar su código.

El conector remoto y el puerto predeterminados han cambiado en JBoss EAP 7. Para detalles sobre este cambio, vea Actualice el puerto y el conector remoto de URL.

Si migra la configuración de su servidor usando el migrate operación, la configuración anterior se conserva y no necesita actualizar su PROVIDER_URL. Sin embargo, si ejecuta con la nueva configuración predeterminada de JBoss EAP 7, debe cambiar el PROVIDER_URL en el código del cliente para usar el nuevo http-remoting://localhost:8080 ajuste. Para más información, ver Migrar código de nombre de cliente remoto.

Si planea migrar su código para usar la API JMS 2.0, consulte la helloworld-jms inicio rápido para un ejemplo de trabajo.

JBoss EAP 6 incluyó el org.hornetq módulo, que le permitió usar el API HornetQ en el código fuente de tu aplicación.

Apache ActiveMQ Artemis reemplaza HornetQ en JBoss EAP 7, por lo que debe migrar cualquier código que use la API HornetQ para usar el API Apache ActiveMQ Artemis. Las bibliotecas para esta API están incluidas en org.apache.activemq.artemis módulo.

ActiveMQ Artemis es una evolución de HornetQ, por lo que muchos de los conceptos se siguen aplicando.

Clases de Interceptor y Cuerpo de Mensaje

JSR 311: JAX-RS: la API de Java ™ para servicios web RESTful no incluyó un marco interceptor, por lo que RESTEasy 2 proporcionó uno. JSR 339: JAX-RS 2.0: la API de Java para los servicios web RESTful introdujo un interceptor oficial y un marco de filtro, por lo que el marco de interceptor incluido en RESTEasy 2 ahora está en desuso, y se reemplazó por el recurso interceptor compatible con JAX-RS 2.0 en RESTEasy 3.x. Las interfaces relevantes se definen en javax.ws.rs.ext paquete de la jaxrs-api módulo.

Para obtener más información acerca de los interceptores, consulte Interceptores RESTEasy en Desarrollo de aplicaciones de servicios web para JBoss EAP.

Para obtener más información sobre la nueva API de reemplazo, consulte la RESTEasy JAX-RS 3.0.13.Final API o después.

API cliente

El marco de trabajo RESTEasy en resteasy-jaxrs ha sido reemplazado por el cumplimiento de JAX-RS 2.0 resteasy-client módulo. Como resultado, algunas clases y métodos de API de cliente RESTEasy están en desuso.

StringConverter

los org.jboss.resteasy.spi.StringConverter la clase está obsoleta en RESTEasy 3.x. Esta funcionalidad puede ser reemplazada usando el JAX-RS 2.0 jax.ws.rs.ext.ParamConverterProvider clase.

ResteasyProviderFactory Agregar métodos

La mayoría de org.jboss.resteasy.spi.ResteasyProviderFactory add() los métodos se han eliminado o protegido en RESTEasy 3.0. Por ejemplo, el addBuiltInMessageBodyReader() y addBuiltInMessageBodyWriter() métodos se han eliminado y el addMessageBodyReader() y addMessageBodyWriter() los métodos han sido protegidos.

Ahora debería usar el registerProvider() y registerProviderInstance() métodos.

Clases adicionales eliminadas de RESTEasy 3

los @org.jboss.resteasy.annotations.cache.ServerCached la anotación, que especificaba que la respuesta al método JAX-RS debe almacenarse en caché en el servidor, se eliminó de RESTEasy 3 y debe eliminarse del código de la aplicación.

SignedInput y SignedOuput

Cambios en WS-Security

Los filtros de seguridad para @RolesAllowed, @PermitAll, y @DenyAll ahora devuelve "403 Prohibido" en lugar de "401 no autorizado".

Filtros del lado del cliente

Los nuevos filtros JAX-RS 2.0 del lado del cliente no se vincularán y ejecutarán cuando utilice la API del cliente RESTEasy de la versión anterior.

Soporte HTTP asíncrono

Porque la especificación JAX-RS 2.0 agrega soporte HTTP asíncrono usando el @Suspended anotación y el AsynResponse interfaz, la API patentada RESTEasy para HTTP asíncrono ha quedado obsoleta y podría eliminarse en una futura versión RESTEasy. Los módulos asíncronos Tomcat y Asincrónicos de JBoss Web también se han eliminado de la instalación del servidor. Si no está utilizando el contenedor Servlet 3.0 o superior, se simulará el procesamiento asincrónico del lado del servidor HTTP y se ejecutará de forma síncrona en el mismo hilo de solicitud.

Caché del lado del servidor

La configuración de la memoria caché del lado del servidor ha cambiado. Por favor mira el Documentación RESTEasy para más información.

Cambios de Jackson Provider [Esto es una traducción automática]

En versiones anteriores de JBoss EAP, la configuración del proveedor RESTEasy YAML estaba habilitada de manera predeterminada. Esto ha cambiado en JBoss EAP 7. El proveedor YAML ahora está deshabilitado por defecto. Su uso no es compatible debido a un problema de seguridad en el SnakeYAML biblioteca utilizada por RESTEasy para desasignación y debe estar explícitamente habilitada en la aplicación. Para obtener información sobre cómo habilitar el proveedor YAML en su aplicación y agregar las dependencias Maven, consulte Proveedor de YAML en Desarrollo de aplicaciones de servicios web para JBoss EAP.

Charset predeterminado UTF-8 en el encabezado de tipo de contenido

En JBoss EAP 7.1, el resteasy.add.charset parámetro está configurado para true por defecto. Puedes configurar el resteasy.add.charset parámetro a false si no quieres que RESTEasy agregue charset=UTF-8 al encabezado de tipo de contenido devuelto cuando el método de recurso devuelve un text/* o application/xml* tipo de medio sin un conjunto de caracteres explícito.

Para obtener más información acerca de los tipos de medios de texto y conjuntos de caracteres, consulte Tipos de medios de texto y juegos de caracteres en Desarrollo de aplicaciones de servicios web para JBoss EAP.

SerializableProvider

Deserializar objetos Java de fuentes no confiables no es seguro. Por esta razón, en JBoss EAP 7, el org.jboss.resteasy.plugins.providers.SerializableProvider la clase está deshabilitada de forma predeterminada, y no se recomienda utilizar este proveedor.

Coincidencia de solicitudes a métodos de recursos

En RESTEasy 3, se han realizado mejoras y correcciones en la implementación de las reglas de coincidencia, tal como se define en la especificación JAX-RS 2.0. En particular, se realizó un cambio en cómo se maneja un URI ambiguo en un método de sub-recursos y un localizador de sub-recursos.

En RESTEasy 2, era posible que un localizador de sub-recursos se ejecutara con éxito incluso cuando había otro sub-recurso con el mismo URI. Este comportamiento fue incorrecto según la especificación.

En RESTEasy 3, cuando hay un URI ambiguo para un sub-recurso y un localizador de sub-recursos, la invocación del sub-recurso será exitosa; sin embargo, llamar al localizador de sub-recursos dará como resultado un estado HTTP 405 Method Not Allowed error.

El siguiente ejemplo contiene un ambiguo @Path anotación en un método de sub-recurso y un localizador de sub-recursos. Observe que el URI para ambos extremos, anotherResource y anotherResourceLocator, es el mismo. La diferencia entre los dos puntos finales es que anotherResource método está asociado con el verbo REST, POST. los anotherResourceLocator método no está asociado con ningún verbo REST. De acuerdo con la especificación, el punto final con el verbo REST, en este caso el anotherResource método, siempre será seleccionado.

@Path("myResource")
public class ExampleSubResources {
    @POST
    @Path("items")
    @Produces("text/plain")
    public Response anotherResource(String text) {
        return Response.ok("ok").build();
    }

    @Path("items")
    @Produces("text/plain")
    public SubResource anotherResourceLocator() {
        return new SubResource();
    }
}

Excepciones de SPI

Todas las excepciones de falla de SPI han quedado obsoletas y ya no se usan internamente. Han sido reemplazados con la excepción JAX-RS 2.0 correspondiente.

InjectorFactory y registro

los InjectorFactory y Registry SPI han cambiado. Esto no debería ser un problema si usa RESTEasy como está documentado y es compatible.

La versión de Jackson incluida en JBoss EAP ha cambiado. La versión anterior de JBoss EAP incluía Jackson 1.9.9. JBoss EAP 7 ahora incluye Jackson 2.6.3 o superior. Como resultado, el proveedor de Jackson ha cambiado de resteasy-jackson-provider a resteasy-jackson2-provider.

La actualización a la resteasy-jackson2-provider requiere algunos cambios en el paquete. Por ejemplo, el paquete de anotación de Jackson ha cambiado de org.codehaus.jackson.annotate a com.fasterxml.jackson.annotation.

Para cambiar su aplicación y usar el proveedor predeterminado que se incluyó en la versión anterior de JBoss EAP, consulte Cambiar el proveedor predeterminado de Jackson en Desarrollo de aplicaciones de servicios web para JBoss EAP.

El marco de Spring 4.0 presentó soporte para Java 8. Si planea usar la integración de RESTEasy 3.x con Spring, asegúrese de especificar 4.2.x como la versión mínima de Spring en su implementación, ya que esta es la primera versión estable compatible con JBoss EAP. 7.

El proveedor RESTEasy Jettison JSON está en desuso en JBoss EAP 7 y ya no se agrega a las implementaciones de forma predeterminada. Se le recomienda cambiar al proveedor recomendado de RESTEasy Jackson. Si prefiere continuar usando el proveedor de Jettison, debe definir una dependencia explícita para él en el jboss-deployment-descriptor.xml archivo como se demuestra en el siguiente ejemplo.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
  <deployment>
    <exclusions>
      <module name="org.jboss.resteasy.resteasy-jackson2-provider"/>
      <module name="org.jboss.resteasy.resteasy-jackson-provider"/>
    </exclusions>
    <dependencies>
      <module name="org.jboss.resteasy.resteasy-jettison-provider" services="import"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

Para obtener más información acerca de cómo definir dependencias explícitas, consulte Agregar una dependencia de módulo explícito a una implementación en el JBoss EAP Guía de desarrollo.

Las clases de integración que facilitaron el uso de Hibernate ORM 3 en la versión anterior fueron eliminadas de JBoss EAP 7. Si su aplicación todavía usa las bibliotecas Hibernate ORM 3, se recomienda encarecidamente que migre su aplicación para usar Hibernate ORM 5 como Hibernate ORM 3 ya no funcionará en JBoss EAP sin mucho esfuerzo. Si no puede migrar a Hibernate ORM 5, debe definir un módulo JBoss personalizado para Hibernate ORM 3 JAR y excluir las clases Hibernate ORM 5 de su aplicación.

Si su aplicación necesita caché de segundo nivel habilitada, debe migrar a Hibernate ORM 5, que está integrado con Infinispan 8.x.

Las aplicaciones escritas con Hibernate ORM 4.x aún pueden usar Hibernate ORM 4.x. Debe definir un módulo JBoss personalizado para los JAR de Hibernate ORM 4.x y excluir las clases de Hibernate ORM 5 de su aplicación. Sin embargo, se recomienda encarecidamente que reescriba el código de la aplicación para usar Hibernate ORM 5. Para obtener información sobre la migración a Hibernate ORM 5, consulte Migración a Hibernate ORM 5.

Esta sección destaca los cambios que debe realizar al migrar desde la versión 4.3 de Hibernate ORM a la versión 5. Para obtener más información acerca de los cambios implementados entre Hibernate ORM 4 e Hibernate ORM 5, consulte el Guía de migración de Hibernate ORM 5.0.

RESETClases obsoletas [Esto es una traducción automática]

Las siguientes clases en desuso se eliminaron de Hibernate ORM 5:

Otros cambios a clases y paquetes

Tipo de manejo

Cambios en el subsistema de transacciones [Esto es una traducción automática]

Cambios en la búsqueda de Hibernate [Esto es una traducción automática]

Mientras que JBoss EAP 7.0 incluyó Hibernate ORM 5.0, JBoss EAP 7.1 ahora incluye Hibernate ORM 5.1. Esta sección resalta las diferencias y los cambios necesarios al migrar desde la versión 5.0 de Hibernate ORM a la versión 5.1.

Hibernate ORM 3.0 [Esto es una traducción automática]

Esta versión incluye muchas mejoras de rendimiento y correcciones de errores, que se detallan en Funciones de Hibernate ORM 5.1 en el JBoss EAP 7.1.0 Notas de la versión. Para obtener información adicional sobre los cambios implementados entre Hibernate ORM 5.0 e Hibernate ORM 5.1, consulte el Hibernate ORM 5.1 Guía de migración.

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

Cambios del cliente EJB en JBoss EAP 7 [Esto es una traducción automática]

Los cambios de herramientas de gestión de esquemas en Hibernate ORM 5.1 se centran principalmente en las siguientes áreas:

Los cambios de herramientas de administración de esquemas solo deberían ser un problema de migración para las aplicaciones que usan directamente cualquiera de las siguientes clases:

Cambios en la configuración de mensajería en JBoss EAP 7.1 [Esto es una traducción automática]

Hibernate ORM 5.1.10 que se incluye en JBoss EAP 7.1, introdujo una nueva estrategia para recuperar tablas de bases de datos que mejora SchemaMigrator y SchemaValidator actuación. Esta estrategia ejecuta un solo java.sql.DatabaseMetaData#getTables(String, String, String, String[]) llamar para determinar si cada javax.persistence.Entity tiene una tabla de base de datos mapeada. Esta es la estrategia predeterminada, y usa el hibernate.hbm2ddl.jdbc_metadata_extraction_strategy=grouped ajuste de propiedad. Esta estrategia puede requerir hibernate.default_schema y / o hibernate.default_catalog ser provisto.

Para usar la vieja estrategia, que ejecuta un java.sql.DatabaseMetaData#getTables(String, String, String, String[]) pedir each javax.persistence.Entity, utilizar el hibernate.hbm2ddl.jdbc_metadata_extraction_strategy=individually ajuste de propiedad.

En JBoss EAP 7.0, la comprobación de errores del contexto de persistencia no sincronizada no fue tan estricta como debería haber sido en las siguientes áreas.

En adición, PersistenceProperty consejos en el @PersistenceContext fueron ignorados por error en JBoss EAP 7.0.

Estos problemas fueron abordados y corregidos en JBoss EAP 7.1. Debido a que estas actualizaciones pueden dar como resultado un cambio no deseado en el comportamiento de la aplicación, se introdujeron dos nuevas propiedades de unidad de persistencia en JBoss EAP 7.1 para proporcionar compatibilidad con versiones anteriores y preservar el comportamiento anterior.

El conector remoto y el puerto predeterminados han cambiado en JBoss EAP 7. Para detalles sobre este cambio, vea Actualice el puerto y el conector remoto de URL.

Si usaste el migrate operación para migrar la configuración de su servidor, se conservan las configuraciones anteriores y no es necesario realizar los cambios detallados a continuación. Sin embargo, si ejecuta con la nueva configuración predeterminada de JBoss EAP 7, debe realizar los siguientes cambios.

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

Si está ejecutando la nueva configuración predeterminada de JBoss EAP 7, debe modificar su código de cliente para usar el nuevo puerto y conector remoto predeterminado.

El siguiente es un ejemplo de cómo se especificaron las propiedades de denominación remota en el código de cliente en JBoss EAP 6.

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=remote://localhost:4447

El siguiente es un ejemplo de cómo especificar las propiedades de nombres remotos en el código de cliente en JBoss EAP 7.

java.naming.factory.initial=org.wildfly.naming.client.WildFlyInitialContextFactory
java.naming.provider.url=http-remoting://localhost:8080

Mientras que JBoss EAP 7.0 se envía con JBoss EJB Client 2.1.4, JBoss EAP 7.1 se envía con JBoss EJB Client 4.0.x, que incluye una serie de cambios en la API.

Si creó una válvula autenticadora personalizada que se extendió AuthenticatorBase en JBoss EAP 6.4, debe reemplazarlo manualmente con una implementación de autenticación HTTP personalizada en JBoss EAP 7.1. El mecanismo de autenticación HTTP se crea en elytron subsistema y luego registrado con el undertow subsistema. Para obtener información sobre cómo implementar un mecanismo de autenticación HTTP personalizado, consulte Implementación de un mecanismo HTTP personalizado en el Guía de desarrollo para JBoss EAP.

Para obtener información sobre los cambios necesarios para SSO con la configuración de SAML v2, consulte Cambios de las versiones anteriores de JBoss EAP en Cómo configurar SSO con SAML v2 para JBoss EAP.

Para obtener información sobre las diferencias en la configuración de SSO con Kerberos, consulte Diferencias con la configuración de versiones anteriores JBoss EAP en Cómo configurar SSO con Kerberos para JBoss EAP.

La siguiente lista describe algunas de las nuevas características de clúster a tener en cuenta al migrar su aplicación de JBoss EAP 6 a JBoss EAP 7.

El resto de esta sección describe cómo los cambios en la agrupación pueden afectar la migración de sus aplicaciones a JBoss EAP 7.

JBoss EAP 7 presenta una nueva implementación de clustering de sesión web. Reemplaza la implementación anterior, que estaba estrechamente relacionada con el código fuente del subsistema web JBoss.

La implementación de la nueva agrupación de sesiones web impacta la forma en que se configura la aplicación en el jboss-web.xml Archivo de descriptor XML de la aplicación web propiedad de JBoss EAP. Los siguientes son los únicos elementos de configuración de clúster que permanecen en este archivo.

<jboss-web>
  ...
  <max-active-sessions>...</max-active-sessions>
  ...
  <replication-config>
    <replication-granularity>...</replication-granularity>
    <cache-name>...</cache-name>
  </replication-config>
  ...
</jboss-web>

La siguiente tabla describe cómo lograr un comportamiento similar para los elementos en el jboss-web.xml archivo que ahora está obsoleto.

Esta nueva implementación también es compatible con las tiendas de caché de escritura simultánea, así como las tiendas de caché solo de pasivación. Normalmente, se usa un almacén de caché de escritura simultánea junto con un caché de invalidación. La implementación de clústeres de sesiones web en JBoss EAP 6 no funcionaba correctamente cuando se utilizaba con un caché de invalidación.

En JBoss EAP 6, se le solicitó que habilitara el comportamiento de clúster para beans de sesión con estado (SFSB) de una de las siguientes maneras.

JBoss EAP 7 ya no requiere que habilite el comportamiento de agrupamiento. De forma predeterminada, si el servidor se inicia utilizando un perfil HA, el estado de los SFSB se replicará automáticamente.

Puede deshabilitar este comportamiento predeterminado de una de las siguientes maneras.

En JBoss EAP 6, las API para servicios de clustering estaban en módulos privados y no eran compatibles.

JBoss EAP 7 presenta una API de servicios públicos de clustering para uso de las aplicaciones. Los nuevos servicios están diseñados para ser livianos, fácilmente inyectables y no requieren dependencias externas.

Estos servicios reemplazan API similares que estaban disponibles en versiones anteriores, es decir, HAPartition de JBoss EAP 5 y GroupCommunicationService, GroupMembershipNotifier, y GroupRpcDispatcher en JBoss EAP 6.

Para más información, ver API pública para servicios de clúster en el JBoss EAP Guía de desarrollo.

En JBoss EAP 6, no había una API pública disponible para el servicio de singleton HA de todo el clúster. Si usaste el privado org.jboss.as.clustering.singleton.* clases, debe cambiar su código para usar el nuevo público org.wildfly.clustering.singleton.* paquetes cuando migre su aplicación a JBoss EAP 7.

Para obtener más información acerca de los servicios de HA singleton, consulte Servicio HA Singleton en el Guía de desarrollo para JBoss EAP. Para obtener información acerca de las implementaciones de HA singleton, consulte Despliegues HA Singleton en el Guía de desarrollo para JBoss EAP.

La bóveda que se usó para almacenar el cifrado de cadenas de texto sin formato en el legado security El subsistema en JBoss EAP 7.0 no es compatible con Elytron en JBoss EAP 7.1, que utiliza un almacén de credenciales recientemente diseñado para almacenar cadenas. Las tiendas de credenciales cifran las credenciales de forma segura en un archivo de almacenamiento externo a los archivos de configuración de JBoss EAP. Puede usar la implementación provista por Elytron o puede personalizar la configuración usando las API y SPI del store de credenciales. Cada servidor JBoss EAP puede contener múltiples tiendas de credenciales.

Si continúas usando el legado security subsistema, no debería necesitar modificar o actualizar sus datos de bóveda. Sin embargo, si planea migrar su aplicación para usar Elytron, debe convertir sus bóvedas existentes en tiendas de credenciales para que puedan ser procesadas por el elytron subsistema. Para obtener más información acerca de las tiendas de credenciales, consulte Tiendas de credenciales en Cómo configurar la seguridad del servidor para JBoss EAP.

Migre los clientes para usar el archivo de configuración de WildFly [Esto es una traducción automática]

La herramienta Wildly Elytron que se envía con JBoss EAP proporciona una vault comando para ayudarlo a migrar el contenido de la bóveda a las tiendas de credenciales. Ejecuta la herramienta ejecutando el elytron-tool script, que se encuentra en EAP_HOME/bin directorio.

$ EAP_HOME/bin/elytron-tool.sh vault VAULT_ARGUMENTS

Si lo prefiere, puede ejecutar la herramienta ejecutando el java -jar mando.

$ java -jar EAP_HOME/bin/wildfly-elytron-tool.jar vault VAULT_ARGUMENTS

Puede usar el siguiente comando para obtener una descripción de todos los argumentos disponibles.

$ EAP_HOME/bin/elytron-tool.sh vault --help

Elija una de las siguientes opciones de migración:

Migre las bóvedas para proteger el almacenamiento de credenciales [Esto es una traducción automática]

El siguiente es un ejemplo del comando utilizado para convertir una única bóveda de seguridad a un almacén de credenciales.

$ EAP_HOME/bin/elytron-tool.sh vault --enc-dir vault_data/ --keystore vault-jceks.keystore --keystore-password MASK-2hKo56F1a3jYGnJwhPmiF5 --iteration 34 --salt 12345678 --alias test --location cs-v1.store --summary

Este comando convierte la bóveda de seguridad en un almacén de credenciales e imprime el resumen de los comandos CLI de administración que se usaron para convertirlo en la salida.

Vault (enc-dir="vault_data/";keystore="vault-jceks.keystore") converted to credential store "cs-v1.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="cs-v1.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})

Migre las bóvedas para proteger el almacenamiento de credenciales [Esto es una traducción automática]

Puede convertir varias bóvedas en una tienda de credenciales utilizando --bulk-convert argumento y apuntando a un archivo descriptor de conversión masiva.

Los ejemplos en esta sección usan el siguiente archivo descriptor de conversión masiva.

keystore:vault-v1/vault-jceks.keystore
keystore-password:MASK-2hKo56F1a3jYGnJwhPmiF5
enc-dir:vault-v1/vault_data/
salt:12345678
iteration:34
location:v1-cs-1.store
alias:test

keystore:vault-v1/vault-jceks.keystore
keystore-password:secretsecret
enc-dir:vault-v1/vault_data/
location:v1-cs-2.store
alias:test

# different vault vault-v1-more
keystore:vault-v1-more/vault-jceks.keystore
keystore-password:MASK-2hKo56F1a3jYGnJwhPmiF5
enc-dir:vault-v1-more/vault_data/
salt:12345678
iteration:34
location:v1-cs-more.store
alias:test

Una nueva conversión comienza cuando cada nuevo keystore: línea se encuentra. Todas las opciones son obligatorias excepto por salt, iteration, y properties.

Para realizar la conversión masiva y generar resultados que formatean los comandos CLI de administración, ejecute el siguiente comando.

$ EAP_HOME/bin/elytron-tool.sh vault --bulk-convert path/to/bulk-vault-conversion-descriptor.txt --summary

Este comando convierte todas las bóvedas de seguridad especificadas en el archivo en un almacén de credenciales e imprime el resumen de los comandos CLI de administración que se usaron para convertirlos en el resultado.

Vault (enc-dir="vault-v1/vault_data/";keystore="vault-v1/vault-jceks.keystore") converted to credential store "v1-cs-1.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-1.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})
--------------------------------------

Vault (enc-dir="vault-v1/vault_data/";keystore="vault-v1/vault-jceks.keystore") converted to credential store "v1-cs-2.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-2.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="secretsecret"})
--------------------------------------

Vault (enc-dir="vault-v1-more/vault_data/";keystore="vault-v1-more/vault-jceks.keystore") converted to credential store "v1-cs-more.store"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,create=true,modifiable=true,location="v1-cs-more.store",implementation-properties={"keyStoreType"=>"JCEKS"},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"})
--------------------------------------

Los ejemplos en esta sección suponen que group.name y encoding.algorithm las propiedades de seguridad se definen como security-properties en el legado security subsistema de la siguiente manera.

<subsystem xmlns="urn:jboss:domain:security:2.0">
    ...
    <security-properties>
        <property name="group.name" value="engineering-group" />
        <property name="encoding.algorithm" value="BASE64" />
    </security-properties>
</subsystem>

Para definir las mismas propiedades de seguridad en elytron subsistema, configure el security-properties atributo de la elytron subsistema utilizando el siguiente comando CLI de gestión.

/subsystem=elytron:write-attribute(name=security-properties, value={ group.name = "engineering-group", encoding.algorithm = "BASE64" })

Esto configura lo siguiente security-properties en el elytron subsistema en el archivo de configuración del servidor.

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
    <security-properties>
        <security-property name="group.name" value="engineering-group"/>
        <security-property name="encoding.algorithm" value="BASE64"/>
    </security-properties>
    ...
</subsystem>

los write-attribute la operación utilizada en el comando anterior sobrescribe las propiedades existentes. Para agregar o cambiar una propiedad de seguridad sin afectar otras propiedades de seguridad, use la map operación en el comando CLI de administración.

/subsystem=elytron:map-put(name=security-properties, key=group.name, value=technical-support)

De manera similar, puede eliminar una propiedad de seguridad específica utilizando el map-remove operación.

/subsystem=elytron:map-remove(name=security-properties, key=group.name)

Esta sección describe cómo migrar la autenticación LDAP heredada a Elytron para que pueda administrar la información como atributos de identidad. Gran parte de la información proporcionada en la sección titulada Migre la autenticación y autorización basada en las propiedades a Elytron se aplica aquí, particularmente con respecto a cómo definir dominios de seguridad y fábricas de autenticación, y cómo mapearlas para ser utilizadas para la autenticación. Esta sección no repite esas instrucciones, así que asegúrese de leer esa sección antes de continuar.

Los siguientes ejemplos suponen que la información de grupo o rol se carga directamente desde LDAP y que la autenticación LDAP heredada se configura de la siguiente manera.

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-realms>
    ...
    <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
      <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
        <attribute-mapping>
          <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
        </attribute-mapping>
      </identity-mapping>
    </ldap-realm>
  </security-realms>
  ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
</subsystem>

Esta sección describe cómo migrar la autenticación de PicketBox basada en la fuente de datos JDBC a Elytron. Gran parte de la información proporcionada en la sección titulada Migre la autenticación y autorización basada en las propiedades a Elytron se aplica aquí, particularmente con respecto a cómo definir dominios de seguridad y fábricas de autenticación, y cómo mapearlas para ser utilizadas para la autenticación. Esta sección no repite esas instrucciones, así que asegúrese de leer esa sección antes de continuar.

Los siguientes ejemplos suponen que los datos de autenticación de usuario se almacenan en una tabla de base de datos creada usando sintaxis similar al ejemplo siguiente.

CREATE TABLE User (
    id BIGINT NOT NULL,
    username VARCHAR(255),
    password VARCHAR(255),
    role ENUM('admin', 'manager', 'user'),
    PRIMARY KEY (id),
    UNIQUE (username)
)

Para fines de autenticación, el nombre de usuario se compara con los datos almacenados en el username columna, se espera que la contraseña se almacene como un hash MD5 con codificación hexadecimal en el password columna, y la función de usuario para fines de autorización se almacena en role columna.

El dominio de seguridad PicketBox está configurado para usar un origen de datos JBDC para recuperar datos de la tabla de la base de datos, y luego usarlos para verificar el nombre de usuario y la contraseña, y para asignar roles. Supongamos que el dominio de seguridad PicketBox se configura con los siguientes comandos CLI de administración.

/subsystem=security/security-domain=application-security:add
/subsystem=security/security-domain=application-security/authentication=classic:add( login-modules=[ { code=Database, flag=Required, module-options={ dsJndiName="java:jboss/datasources/ExampleDS", principalsQuery="SELECT password FROM User WHERE username = ?", rolesQuery="SELECT role, 'Roles' FROM User WHERE username = ?", hashAlgorithm=MD5, hashEncoding=base64 } } ] )

Esto resulta en lo siguiente login-module configuración en el legado security subsistema.

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="application-security">
      <authentication>
        <login-module code="Database" flag="required">
          <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
          <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/>
          <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/>
          <module-option name="hashAlgorithm" value="MD5"/>
          <module-option name="hashEncoding" value="base64"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

/subsystem=elytron/jdbc-realm=jdbc-realm:add(principal-query=[ { data-source=ExampleDS, sql="SELECT role, password FROM User WHERE username = ?", attribute-mapping=[{index=1, to=Roles } ] simple-digest-mapper={algorithm=simple-digest-md5, password-index=2} } ] )

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-realms>
    ...
    <jdbc-realm name="jdbc-realm">
      <principal-query sql="SELECT role, password FROM User WHERE username = ?" data-source="ExampleDS">
        <attribute-mapping>
          <attribute to="Roles" index="1"/>
        </attribute-mapping>
        <simple-digest-mapper password-index="2"/>
      </principal-query>
    </jdbc-realm>
    ...
  </security-realms>
  ...
</subsystem>

Cuando se trabaja con una configuración de Kerberos, el servidor JBoss EAP puede confiar en la información de configuración del entorno, o la configuración de la clave se puede especificar utilizando las propiedades del sistema. Esta sección explica cómo migrar Kerberos HTTP y Kerberos SASL autenticación.

Los ejemplos que siguen suponen que Kerberos se configura utilizando las siguientes propiedades del sistema. Estas propiedades del sistema son aplicables tanto a la configuración heredada como a la configuración migrada de Elytron.

# Enable debugging
/system-property=sun.security.krb5.debug:add(value=true)
# Identify the Kerberos realm to use
/system-property=java.security.krb5.realm:add(value=ELYTRON.ORG)
# Identify the address of the KDC
/system-property=java.security.krb5.kdc:add(value=kdc.elytron.org)

<system-properties>
  <property name="sun.security.krb5.debug" value="true"/>
  <property name="java.security.krb5.realm" value="ELYTRON.ORG"/>
  <property name="java.security.krb5.kdc" value="kdc.elytron.org"/>
</system-properties>

Elija una de las siguientes opciones de migración:

Migre la autenticación de Kerberos a Elytron [Esto es una traducción automática]

En las configuraciones de seguridad heredadas, puede definir un reino de seguridad para habilitar la autenticación SPNEGO para la interfaz de administración HTTP de la siguiente manera.

/core-service=management/security-realm=Kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos/keytab=HTTP\/test-server.elytron.org@ELYTRON.ORG:add(path=/path/to/test-server.keytab, debug=true)
/core-service=management/security-realm=Kerberos/authentication=kerberos:add(remove-realm=true)

<security-realms>
  ...
  <security-realm name="Kerberos">
    <server-identities>
      <kerberos>
        <keytab principal="HTTP/test-server.elytron.org@ELYTRON.ORG" path="/path/to/test-server.keytab" debug="true"/>
      </kerberos>
    </server-identities>
    <authentication>
      <kerberos remove-realm="true"/>
    </authentication>
  </security-realm>
</security-realms>

También puede definir un par de dominios de seguridad heredados para permitir que las aplicaciones utilicen la autenticación HTTP de Kerberos.

# Define the first security domain
/subsystem=security/security-domain=host:add
/subsystem=security/security-domain=host/authentication=classic:add
/subsystem=security/security-domain=host/authentication=classic/login-module=1:add(code=Kerberos, flag=Required, module-options={storeKey=true, useKeyTab=true, principal=HTTP/test-server.elytron.org@ELYTRON.ORG, keyTab=path/to/test-server.keytab, debug=true}

# Define the second SPNEGO security domain
/subsystem=security/security-domain=SPNEGO:add
/subsystem=security/security-domain=SPNEGO/authentication=classic:add
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=1:add(code=SPNEGO, flag=requisite,  module-options={password-stacking=useFirstPass, serverSecurityDomain=host})
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=1:write-attribute(name=module, value=org.jboss.security.negotiation)
/subsystem=security/security-domain=SPNEGO/authentication=classic/login-module=2:add(code=UsersRoles, flag=required, module-options={password-stacking=useFirstPass, usersProperties=  /path/to/kerberos/spnego-users.properties, rolesProperties=  /path/to/kerberos/spnego-roles.properties, defaultUsersProperties=  /path/to/kerberos/spnego-users.properties, defaultRolesProperties=  /path/to/kerberos/spnego-roles.properties})

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="host">
      <authentication>
        <login-module name="1" code="Kerberos" flag="required">
          <module-option name="storeKey" value="true"/>
          <module-option name="useKeyTab" value="true"/>
          <module-option name="principal" value="HTTP/test-server.elytron.org@ELYTRON.ORG"/>
          <module-option name="keyTab" value="/path/to/test-server.keytab"/>
          <module-option name="debug" value="true"/>
        </login-module>
      </authentication>
    </security-domain>
    <security-domain name="SPNEGO">
      <authentication>
        <login-module name="1" code="SPNEGO" flag="requisite" module="org.jboss.security.negotiation">
          <module-option name="password-stacking" value="useFirstPass"/>
          <module-option name="serverSecurityDomain" value="host"/>
        </login-module>
        <login-module name="2" code="UsersRoles" flag="required">
          <module-option name="password-stacking" value="useFirstPass"/>
          <module-option name="usersProperties" value="path/to/kerberos/spnego-users.properties"/>
          <module-option name="rolesProperties" value="  /path/to/kerberos/spnego-roles.properties"/>
          <module-option name="defaultUsersProperties" value="  /path/to/kerberos/spnego-users.properties"/>
          <module-option name="defaultRolesProperties" value="  /path/to/kerberos/spnego-roles.properties"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

Las aplicaciones heredadas luego se implementan haciendo referencia al dominio de seguridad SPNEGO y aseguradas con el mecanismo SPNEGO.

Migre la autenticación de Kerberos a Elytron [Esto es una traducción automática]

Tanto la interfaz de administración como las aplicaciones se pueden proteger en Elytron utilizando un reino de seguridad y una fábrica de seguridad Kerberos.

Migre la autenticación de Kerberos a Elytron [Esto es una traducción automática]

Es posible definir un reino de seguridad heredado para la autenticación Kerberos / GSSAPI SASL que se utilizará para la autenticación remota, como la interfaz de administración nativa.

/core-service=management/security-realm=Kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos:add
/core-service=management/security-realm=Kerberos/server-identity=kerberos/keytab=remote\/test-server.elytron.org@ELYTRON.ORG:add(path=path/to/remote-test-server.keytab, debug=true)
/core-service=management/security-realm=Kerberos/authentication=kerberos:add(remove-realm=true)

<management>
  <security-realms>
    ...
    <security-realm name="Kerberos">
      <server-identities>
        <kerberos>
          <keytab principal="remote/test-server.elytron.org@ELYTRON.ORG" path="path/to/remote-test-server.keytab" debug="true"/>
        </kerberos>
      </server-identities>
      <authentication>
        <kerberos remove-realm="true"/>
      </authentication>
    </security-realm>
  </security-realms>
  ...
</management>

Migre la autenticación de Kerberos a Elytron [Esto es una traducción automática]

Los pasos para definir la configuración de Elytron equivalente son muy similares a los descritos en Migrar autenticación Kerberos HTTP.

Esto da como resultado la siguiente configuración en elytron subsistema del archivo de configuración del servidor.

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="KerberosDomain" default-realm="kerberos-properties" permission-mapper="default-permission-mapper">
      <realm name="kerberos-properties" role-decoder="groups-to-roles"/>
    </security-domain>
  </security-domains>
  <security-realms>
   ...
     <properties-realm name="kerberos-properties">
       <users-properties path="kerberos-users.properties" relative-to="kerberos" digest-realm-name="ELYTRON.ORG"/>
       <groups-properties path="kerberos-groups.properties" relative-to="kerberos"/>
     </properties-realm>
   </security-realms>
   <credential-security-factories>
     <kerberos-security-factory name="test-server" principal="remote/test-server.elytron.org@ELYTRON.ORG" path="remote-test-server.keytab" relative-to="kerberos"/>
   </credential-security-factories>
   ...
   <sasl>
     ...
     <sasl-authentication-factory name="gssapi-authentication-factory" sasl-server-factory="elytron" security-domain="KerberosDomain">
       <mechanism-configuration>
         <mechanism mechanism-name="GSSAPI" credential-security-factory="test-server"/>
       </mechanism-configuration>
     </sasl-authentication-factory>
     ...
   </sasl>
 </subsystem>

La interfaz de gestión o los conectores remotos ahora se pueden actualizar para hacer referencia a la fábrica de autenticación SASL.

Los dos ejemplos de Elytron definidos aquí también podrían combinarse para usar un dominio de seguridad y un dominio de seguridad compartidos y simplemente usar fábricas de autenticación específicas del protocolo cada una haciendo referencia a su propia fábrica de seguridad de Kerberos.

Esta sección describe cómo migrar un PicketBox o reino de seguridad heredado configuración que usa múltiples almacenes de identidad para Elitrono. Al utilizar PicketBox o los reinos de seguridad heredados, es posible definir una configuración donde la autenticación se realiza en un único almacén de identidades mientras que la información utilizada para la autorización se carga desde un almacén diferente. Al migrar a Elytron, esto se puede lograr mediante el uso de un reino de seguridad agregado.

Los siguientes ejemplos realizan autenticación de usuario utilizando el example-users.properties archivo de propiedades, y luego consulta LDAP para cargar la información del grupo y la función.

Ejemplo: Configuración de PicketBox LoginModule [Esto es una traducción automática]

El dominio de seguridad PicketBox para este escenario se configura mediante los siguientes comandos CLI de administración.

/subsystem=security/security-domain=application-security:add

/subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[ {code=UsersRoles, flag=Required, module-options={ password-stacking=useFirstPass, usersProperties=file://${jboss.server.config.dir}/example-users.properties}} {code=LdapExtended, flag=Required, module-options={ password-stacking=useFirstPass, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])

Esto da como resultado la siguiente configuración de servidor.

<security-domain name="application-security">
  <authentication>
    <login-module code="UsersRoles" flag="required">
      <module-option name="password-stacking" value="useFirstPass"/>
      <module-option name="usersProperties" value="file://${jboss.server.config.dir}/example-users.properties"/>
    </login-module>
    <login-module code="LdapExtended" flag="required">
      <module-option name="password-stacking" value="useFirstPass"/>
      <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
      <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
      <module-option name="java.naming.security.authentication" value="simple"/>
      <module-option name="bindDN" value="uid=admin,ou=system"/>
      <module-option name="bindCredential" value="secret"/>
      <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/>
      <module-option name="baseFilter" value="(uid={0})"/>
      <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
      <module-option name="roleFilter" value="(uniqueMember={1})"/>
      <module-option name="roleAttributeID" value="uid"/>
    </login-module>
  </authentication>
</security-domain>

Ver Configuración del reino de seguridad agregada de Elytron para saber cómo configurar un reino de seguridad agregado en el elytron subsistema para lograr esto.

Ejemplo: Comandos de configuración de dominios de seguridad heredados [Esto es una traducción automática]

La configuración del reino de seguridad heredada para este escenario se configura mediante los siguientes comandos CLI de administración.

/core-service=management/ldap-connection=MyLdapConnection:add(url="ldap://localhost:10389", search-dn="uid=admin,ou=system", search-credential="secret")

/core-service=management/security-realm=ApplicationSecurity:add
/core-service=management/security-realm=ApplicationSecurity/authentication=properties:add(path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true)

batch
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap:add(connection=MyLdapConnection)
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap/username-to-dn=username-filter:add(attribute=uid, base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org")
/core-service=management/security-realm=ApplicationSecurity/authorization=ldap/group-search=group-to-principal:add(base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", iterative=true, prefer-original-connection=true, principal-attribute=uniqueMember, search-by=DISTINGUISHED_NAME, group-name=SIMPLE, group-name-attribute=uid)
run-batch

Esto da como resultado la siguiente configuración de servidor.

<security-realms>
  ...
  <security-realm name="ApplicationSecurity">
    <authentication>
      <properties path="example-users.properties" relative-to="jboss.server.config.dir" plain-text="true"/>
    </authentication>
    <authorization>
      <ldap connection="MyLdapConnection">
        <username-to-dn>
          <username-filter base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org" attribute="uid"/>
        </username-to-dn>
        <group-search group-name="SIMPLE" iterative="true" group-name-attribute="uid">
          <group-to-principal search-by="DISTINGUISHED_NAME" base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org" prefer-original-connection="true">
            <membership-filter principal-attribute="uniqueMember"/>
          </group-to-principal>
        </group-search>
      </ldap>
    </authorization>
  </security-realm>
</security-realms>
<outbound-connections>
  <ldap name="MyLdapConnection" url="ldap://localhost:10389" search-dn="uid=admin,ou=system" search-credential="secret"/>
</outbound-connections>

Ver Configuración del reino de seguridad agregada de Elytron para saber cómo configurar un reino de seguridad agregado en el elytron subsistema para lograr esto.

Ejemplo: Configuración de LDAP Security Realm [Esto es una traducción automática]

La configuración equivalente de Elytron para este escenario se configura con los siguientes comandos CLI de administración.

/subsystem=elytron/dir-context=ldap-connection:add(url=ldap://localhost:10389, principal="uid=admin,ou=system", credential-reference={clear-text=secret})

/subsystem=elytron/ldap-realm=ldap-realm:add(dir-context=ldap-connection, direct-verification=true, identity-mapping={search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org", rdn-identifier="uid", attribute-mapping=[{filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org",filter="(uniqueMember={1})",from="uid",to="Roles"}]})

/subsystem=elytron/properties-realm=application-properties:add(users-properties={path=example-users.properties, relative-to=jboss.server.config.dir, plain-text=true, digest-realm-name="Application Security"})

/subsystem=elytron/aggregate-realm=combined-realm:add(authentication-realm=application-properties, authorization-realm=ldap-realm)

/subsystem=elytron/security-domain=application-security:add(realms=[{realm=combined-realm}], default-realm=combined-realm, permission-mapper=default-permission-mapper)
/subsystem=elytron/http-authentication-factory=application-security-http:add(http-server-mechanism-factory=global, security-domain=application-security, mechanism-configurations=[{mechanism-name=BASIC}])

Esto da como resultado la siguiente configuración de servidor.

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="application-security" default-realm="combined-realm" permission-mapper="default-permission-mapper">
      <realm name="combined-realm"/>
    </security-domain>
  </security-domains>
  <security-realms>
    <aggregate-realm name="combined-realm" authentication-realm="application-properties" authorization-realm="ldap-realm"/>
      ...
      <properties-realm name="application-properties">
        <users-properties path="example-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="Application Security" plain-text="true"/>
      </properties-realm>
      <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
        <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
          <attribute-mapping>
            <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
          </attribute-mapping>
        </identity-mapping>
      </ldap-realm>
  </security-realms>
  ...
  <http>
    ...
    <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
      <mechanism-configuration>
        <mechanism mechanism-name="BASIC"/>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
  </http>
  ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
</subsystem>

En el elytron subsistema, un aggregate-realm ha sido definido que especifica qué dominios de seguridad usar para la autenticación y cuáles usar para las decisiones de autorización.

Al usar PicketBox, es posible definir un dominio de seguridad y habilitar el almacenamiento en memoria caché en memoria para su acceso. Esto le permite acceder a los datos de identidad en la memoria y evita el acceso directo adicional al almacén de identidades. Es posible lograr una configuración similar con Elytron. Esta sección describe cómo configurar el almacenamiento en caché del dominio de seguridad cuando se usa Elytron.

Ejemplo: configuración de dominio de seguridad en caché PicketBox [Esto es una traducción automática]

Los siguientes comandos muestran cómo configurar un dominio de seguridad PicketBox que permite el almacenamiento en caché.

/subsystem=security/security-domain=application-security:add(cache-type=default)
/subsystem=security/security-domain=application-security/authentication=classic:add(login-modules=[{code=LdapExtended, flag=Required, module-options={ java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.authentication=simple, bindDN="uid=admin,ou=system", bindCredential=secret, baseCtxDN="ou=users,dc=group-to-principal,dc=wildfly,dc=org", baseFilter="(uid={0})", rolesCtxDN="ou=groups,dc=group-to-principal,dc=wildfly,dc=org", roleFilter="(uniqueMember={1})", roleAttributeID="uid" }}])

Esto da como resultado la siguiente configuración de servidor.

<subsystem xmlns="urn:jboss:domain:security:2.0">
  <security-domains>
    ...
    <security-domain name="application-security" cache-type="default">
      <authentication>
        <login-module code="LdapExtended" flag="required">
          <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
          <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
          <module-option name="java.naming.security.authentication" value="simple"/>
          <module-option name="bindDN" value="uid=admin,ou=system"/>
          <module-option name="bindCredential" value="secret"/>
          <module-option name="baseCtxDN" value="ou=users,dc=group-to-principal,dc=wildfly,dc=org"/>
          <module-option name="baseFilter" value="(uid={0})"/>
          <module-option name="rolesCtxDN" value="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
          <module-option name="roleFilter" value="(uniqueMember={1})"/>
          <module-option name="roleAttributeID" value="uid"/>
        </login-module>
      </authentication>
    </security-domain>
  </security-domains>
</subsystem>

Ejemplo: configuración de dominio de seguridad en caché Elytron [Esto es una traducción automática]

Siga los pasos a continuación para crear una configuración similar que almacena en caché un dominio de seguridad cuando usa Elytron.

Estos comandos dan como resultado las siguientes adiciones a la configuración del servidor.

<subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
  ...
  <security-domains>
    ...
    <security-domain name="application-security" default-realm="cached-ldap" permission-mapper="default-permission-mapper">
      <realm name="cached-ldap"/>
    </security-domain>
  </security-domains>
  ...
  <security-realms>
    ....
  <ldap-realm name="ldap-realm" dir-context="ldap-connection" direct-verification="true">
      <identity-mapping rdn-identifier="uid" search-base-dn="ou=users,dc=group-to-principal,dc=wildfly,dc=org">
        <attribute-mapping>
          <attribute from="uid" to="Roles" filter="(uniqueMember={1})" filter-base-dn="ou=groups,dc=group-to-principal,dc=wildfly,dc=org"/>
        </attribute-mapping>
      </identity-mapping>
    </ldap-realm>
    <caching-realm name="cached-ldap" realm="ldap-realm"/>
  </security-realms>
  ...
  <http>
    ...
    <http-authentication-factory name="application-security-http" http-server-mechanism-factory="global" security-domain="application-security">
      <mechanism-configuration>
        <mechanism mechanism-name="BASIC"/>
      </mechanism-configuration>
    </http-authentication-factory>
    ...
  </http>
   ...
  <dir-contexts>
    <dir-context name="ldap-connection" url="ldap://localhost:10389" principal="uid=admin,ou=system">
      <credential-reference clear-text="secret"/>
    </dir-context>
  </dir-contexts>
  ...

Por defecto, JBoss EAP usa el legado security subsistema para configurar el proveedor de políticas de Contrato de Autorización de Java para Contenedores (JACC) y la fábrica. La configuración predeterminada se asigna a las implementaciones de PicketBox.

los elytron subsistema proporciona un proveedor de políticas incorporado basado en la especificación JACC. Antes de configurar su servidor para permitir que Elytron administre las configuraciones de JACC y otras políticas, primero debe deshabilitar JACC en el legado security subsistema utilizando el siguiente comando de gestión CLI.

/subsystem=security:write-attribute(name=initialize-jacc, value=false)

De lo contrario, puede producirse el siguiente error en el registro del servidor: MSC000004: Failure during stop of service org.wildfly.security.policy: java.lang.StackOverflowError.

Para obtener información sobre cómo habilitar JACC y definir un proveedor de políticas JACC en el elytron subsistema, ver Habilitando JACC Usando el elytron Subsistema en el Guía de desarrollo para JBoss EAP.

Esta sección describe cómo migrar una aplicación cliente que realiza una búsqueda JNDI remota utilizando un org.jboss.naming.remote.client.InitialContext clase, que está respaldado por org.jboss.naming.remote.client.InitialContextFactory clase, a Elytron.

Los siguientes ejemplos suponen que InitialContextFactory la clase se crea especificando las propiedades de las credenciales del usuario y la URL del proveedor de nombres al que se conecta.

Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
properties.put(Context.PROVIDER_URL,"http-remoting://127.0.0.1:8080");
properties.put(Context.SECURITY_PRINCIPAL, "bob");
properties.put(Context.SECURITY_CREDENTIALS, "secret");
InitialContext context = new InitialContext(properties);
Bar bar = (Bar) context.lookup("foo/bar");
...

Puede elegir uno de los siguientes enfoques de migración:

// Create the authentication configuration
AuthenticationConfiguration namingConfig = AuthenticationConfiguration.empty().useName("bob").usePassword("secret");

// Create the authentication context
AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), namingConfig);

// Create a callable that creates and uses an InitialContext
Callable<Void> callable = () -> {
    Properties properties = new Properties();
    properties.put(Context.INITIAL_CONTEXT_FACTORY,"org.wildfly.naming.client.WildFlyInitialContextFactory");
    properties.put(Context.PROVIDER_URL,"remote+http://127.0.0.1:8080");
    InitialContext context = new InitialContext(properties);
    Bar bar = (Bar) context.lookup("foo/bar");
    ...
    return null;
};

// Use the authentication context to run the callable
context.runCallable(callable);

Este ejemplo de migración supone que la aplicación cliente está configurada para invocar un EJB desplegado en un servidor remoto utilizando un jboss-ejb-client.properties archivo. Este archivo, que se encuentra en la aplicación cliente META-INF/ directorio, contiene la siguiente información necesaria para conectarse al servidor remoto.

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=127.0.0.1
remote.connection.default.port = 8080
remote.connection.default.username=bob
remote.connection.default.password=secret

El cliente busca el EJB y llama a uno de sus métodos usando un código similar al del siguiente ejemplo.

// Create an InitialContext
Properties properties = new Properties();
properties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
InitialContext context = new InitialContext(properties);

// Look up the EJB and invoke one of its methods
RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
    "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
int sum = statelessRemoteCalculator.add(101, 202);

Puede elegir uno de los siguientes enfoques de migración:

// Create the authentication configuration
AuthenticationConfiguration ejbConfig = AuthenticationConfiguration.empty().useName("bob").usePassword("secret");

// Create the authentication context
AuthenticationContext context = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), ejbConfig);

// Create a callable that invokes the EJB
Callable<Void> callable = () -> {

    // Create an InitialContext
    Properties properties = new Properties();
    properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
    properties.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080");
    InitialContext context = new InitialContext(properties);

    // Look up the EJB and invoke one of its methods
    // Note that this code is the same as before
    RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
        "ejb:/ejb-remote-server-side//CalculatorBean!" + RemoteCalculator.class.getName());
    int sum = statelessRemoteCalculator.add(101, 202);
    ...
    return null;
};

// Use the authentication context to run the callable
context.runCallable(callable);

Si aseguró conexiones HTTP al servidor JBoss EAP usando un reino de seguridad, puede migrar esa configuración a Elytron utilizando la información proporcionada en esta sección.

Los siguientes ejemplos asumen que tiene lo siguiente keystore configurado en el security-realm.

<security-realm name="ApplicationRealm">
  <server-identities>
    <ssl>
      <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="keystore_password" alias="server" key-password="key_password" />
    </ssl>
  </server-identities>
</security-realm>

Siga los pasos a continuación para lograr la misma configuración usando Elytron.

Esto resulta en lo siguiente elytron configuración del subsistema en el archivo de configuración del servidor.

<subsystem xmlns="urn:wildfly:elytron:1.2" ...>
  ...
  <tls>
    <key-stores>
      <key-store name="LocalhostKeyStore">
        <credential-reference clear-text="keystore_password"/>
        <implementation type="JKS"/>
        <file path="server.keystore" relative-to="jboss.server.config.dir"/>
      </key-store>
    </key-stores>
    <key-managers>
      <key-manager name="LocalhostKeyManager" key-store="LocalhostKeyStore"  alias-filter="server">
        <credential-reference clear-text="key_password"/>
      </key-manager>
    </key-managers>
    <server-ssl-contexts>
      <server-ssl-context name="LocalhostSslContext" key-manager="LocalhostKeyManager"/>
    </server-ssl-contexts>
  </tls>
</subsystem>

Esto resulta en lo siguiente undertow configuración del subsistema en el archivo de configuración del servidor.

<https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/>

Para más información, ver Subsistema Elytron y Cómo proteger las interfaces de administración en Cómo configurar la seguridad del servidor para JBoss EAP.

Si configuró la autenticación SSL de Client-Cert utilizando un almacén de confianza del reino de seguridad, puede migrar esa configuración a Elytron utilizando la información proporcionada en esta sección.

Los pasos siguientes suponen que tiene lo siguiente truststore configurado en el security-realm.

<security-realm name="ApplicationRealm">
  <server-identities>
    <ssl>
      <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="keystore_password" alias="server" key-password="key_password" />
    </ssl>
  </server-identities>
  <authentication>
    <truststore path="server.truststore" relative-to="jboss.server.config.dir" keystore-password="truststore_password" />
    <local default-user="$local"/>
    <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
  </authentication>
  <authorization>
    <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
  </authorization>
</security-realm>

Siga estos pasos para configurar el servidor para evitar que los usuarios sin un certificado válido y una clave privada accedan al servidor utilizando Elytron.

Esto resulta en lo siguiente elytron configuración del subsistema en el archivo de configuración del servidor.

<subsystem xmlns="urn:wildfly:elytron:1.2" ...>
  ...
  <tls>
    <key-stores>
      <key-store name="LocalhostKeyStore">
        <credential-reference clear-text="keystore_password"/>
        <implementation type="JKS"/>
        <file path="server.keystore" relative-to="jboss.server.config.dir"/>
      </key-store>
      <key-store name="TrustStore">
        <credential-reference clear-text="truststore_password"/>
        <implementation type="JKS"/>
        <file path="server.truststore" relative-to="jboss.server.config.dir"/>
      </key-store>
    </key-stores>
    <key-managers>
      <key-manager name="LocalhostKeyManager" key-store="LocalhostKeyStore" alias-filter="server">
        <credential-reference clear-text="key_password"/>
      </key-manager>
    </key-managers>
    <trust-managers>
      <trust-manager name="TrustManager" key-store="TrustStore"/>
    </trust-managers>
    <server-ssl-contexts>
      <server-ssl-context name="LocalhostSslContext" need-client-auth="true" key-manager="LocalhostKeyManager" trust-manager="TrustManager"/>
    </server-ssl-contexts>
  </tls>
</subsystem>

Esto resulta en lo siguiente undertow configuración del subsistema en el archivo de configuración del servidor.

<https-listener name="https" socket-binding="https" ssl-context="LocalhostSslContext" enable-http2="true"/>

Para más información, ver Subsistema Elytron y Usando un cliente-ssl-context en Cómo configurar la seguridad del servidor para JBoss EAP.