Capítulo 5. Cambios en la migración de aplicaciones [Esto es una traducción automática]

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.