1. Primero mire el empaque de su aplicación y sus dependencias. Para mayores detalles consulte: Sección 3.1.2.3, “Actualizar las dependencias de la aplicación debido a los cambios en la carga de clases”

2. Si su aplicación realiza registros entonces necesita especificar las dependencias correctas de los módulos. Para obtener mayor información consulte: Sección 3.1.4.1, “Modificar las dependencias de registros”
3. Debido a los cambios en la carga modular de clases es posible que tenga que cambiar la estructura de empaque de su EAR o WAR. Para obtener mayor información consulte: Sección 3.1.5.1, “Modificación del empaque de EARs y WARs”

Procedimiento 3.1. Dependencias de módulos

1. Dependencias implícitas

   Los implementadores dentro del servidor implícitamente agregan de manera automática algunas dependencias de módulos utilizadas comúnmente como javax.api y sun.jdk. Esto hace que las clases sean visibles para la implementación en el tiempo de ejecución y libera al desarrollador de la tarea de agregar explícitamente las dependencias. Para obtener detalles sobre la manera en que estas dependencias implícitas se agregan, consulte Implicit Module Dependencies en el capítulo titulado Módulos y carga de clases en la Guía de desarrollo para JBoss EAP 6 en https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

2. Dependencias explícitas

   Para otras clases, los módulos se deben especificar explícitamente o de otra manera las dependencias que faltan generan errores en la implementación o en el tiempo de ejecución. Si una dependencia falta entonces verá rastros de ClassNotFoundExceptions o NoClassDefFoundErrors en el registro del servidor. Si más de un módulo carga la misma JAR o un módulo carga una clase que extienda una clase cargada por un módulo diferente podrá ver los rastros ClassCastExceptions en el registro del servidor. Para especificar dependencias de manera explícita, modifique el MANIFEST.MF o cree un archivo descriptor de implementación jboss-deployment-structure.xml específico para JBoss. Para mayor información sobre dependencias de módulos consulte la Overview of Class Loading and Modules en el capítulo titulado Class Loading and Module en la Development Guide para JBoss EAP 6 en https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

Procedimiento 3.2.

1. Si está implementando un archivador WAR tiene que empacar esas propiedades en la carpeta WEB-INF/classes/ del WAR.

2. Si quiere que esas propiedades sean accequibles para todos los componentes en un EAR entonces debe empacarlos en la raíz de una JAR y luego poner la JAR en la carpeta lib/ del EAR.

Procedimiento 3.3. Crear un módulo personalizado

1. Crear y poblar la estructura del directorio module/.
   1. Crear una estructura de directorio bajo el directorio EAP_HOME/module para que contenga los archivos y JARs. Por ejemplo:

      $ cd EAP_HOME/modules/ $ mkdir -p myorg-conf/main/properties
      
      

   2. Mueva el archivo de propiedades al directorio EAP_HOME/modules/myorg-conf/main/properties/ que creó en el paso anterior.
   3. Cree un archivo module.xml en el directorio EAP_HOME/modules/myorg-conf/main/ conteniendo el siguiente XML:

      <module xmlns="urn:jboss:module:1.1" name="myorg-conf">
          <resources>
              <resource-root path="properties"/>
          </resources>
      </module>
      
      

2. Modifique el subsistema ee en el archivo de configuración del servidor. Puede utilizar el CLI JBoss o puede modificar manualmente el archivo.
   • Siga estos pasos para modificar el archivo de configuración usando el CLI JBoss.
     1. Inicie el servidor y conéctese al CLI de administración.
        • Para Linux, ingrese lo siguiente en la línea de comandos:

          $ EAP_HOME/bin/jboss-cli.sh --connect
          

        • Para Windows, ingrese lo siguiente en la línea de comandos:

          C:\>EAP_HOME\bin\jboss-cli.bat --connect
          

        Debe ver la siguiente respuesta:

        Conectado a un controlador autónomo en localhost:9999

     2. Para crear el elemento myorg-conf<global-modules> en el subsistema ee escriba lo siguiente en la línea de comandos:

        /subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])
        

        Debe ver el siguiente resultado:

        {"outcome" => "success"}
        

   • Siga estos pasos si prefiere modificar manualmente el archivo de configuración del servidor.
     1. Detenga el servidor y abra el archivo de configuración del servidor en un editor de texto. Si está ejecutando un servidor autónomo este es el archivo EAP_HOME/standalone/configuration/standalone.xml o el archivo EAP_HOME/domain/configuration/domain.xml si está ejecutando un dominio administrado.
     2. Identifique el subsistema ee y agregue el módulo global para myorg-conf. El siguiente es un ejemplo del elemento subsistema ee modificado para incluir el elemento myorg-conf:

        <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
            <global-modules>
                <module name="myorg-conf" slot="main" />            
            </global-modules>
        </subsystem>
        
        

3. Asumiendo que copió un archivo llamado my.properties en la ubicación correcta del módulo ahora puede cargar archivos de propiedades usando código similar al siguiente:

   Thread.currentThread().getContextClassLoader().getResource("my.properties");
   

Procedimiento 3.4. Actualización del código de registros de la aplicación

1. Sección 3.1.4.2, “Actualización del código de aplicación para marcos de trabajo de registros de terceros”
2. Sección 3.1.4.3, “Modificar el código para utilizar el nuevo marco de trabajo de inicio de sesión JBoss”

Procedimiento 3.5. Configuración de JBoss EAP 6 para utilizar un archivo log4j.properties o log4j.xml

1. Cree un jboss-deployment-structure.xml con el siguiente contenido:

   <jboss-deployment-structure>
       <deployment>
           <!-- Las exclusiones le permiten prevenir que el servidor agregue automáticamente algunas dependencias -->
           <exclusions>
               <module name="org.apache.log4j" />
           </exclusions>
       </deployment>
   </jboss-deployment-structure>
   
   

2. Ponga el archivo jboss-deployment-structure.xml en el directorio META-INF/ o en el directorio WEB-INF/ si está implementando un WAR o en el directorio META-INF/ si está implementando un EAR.
3. Incluya el archivo log4j.properties o log4j.xml en el directorio lib/ de su EAR o el directorio WEB-INF/classes/ de su implementación WAR.
4. Implemente su aplicación.

Procedimiento 3.6. Modificar el código y las dependencias para utilizar el marco de trabajo de inicio de sesión JBoss

1. Cambie sus importaciones y su código de inicio de sesión

   El siguiente es un ejemplo del código que utiliza el nuevo marco de trabajo de inicio de sesión JBoss:

   import org.jboss.logging.Level;
   import org.jboss.logging.Logger;
   
   private static final Logger logger = Logger.getLogger(MyClass.class.toString());
   
   if(logger.isTraceEnabled()) {
       logger.tracef("Starting...", subsystem);
   }
   

2. Agregue la dependencia de inicio de sesión

   La JAR que contiene las clases de inicio de sesión de JBoss se encuentra en el módulo llamado org.jboss.logging. Su archivo MANIFEST-MF se debe ver así:

   Manifest-Version: 1.0
   Dependencies: org.jboss.logging
   

   Para mayor información sobre cómo encontrar la dependencia del módulo consulte Sección 3.1.2.3, “Actualizar las dependencias de la aplicación debido a los cambios en la carga de clases” and Sección 4.2.1, “Depurar y resolver problemas de migración”.

Procedimiento 3.7. Modificación del empaque de archivadores

1. Empaque de un WAR

   Un WAR es un solo módulo y todas las clases en el WAR se cargan con el mismo cargador de clases. Esto significa que las clases empacadas en el directorio WEB-INF/lib/ se tratan de igual manera que las clases en el directorio WEB-INF/classes.

2. Empaque de un EAR

   Un EAR consiste de múltiples módulos. El directorio EAR/lib/ es un solo módulo y toda subimplementación EJB jar o WAR dentro del EAR es un módulo separado. Las clases no tienen acceso a las clases en otros módulos dentro del EAR a menos de que se hayan definido dependencias explícitas. Las subimplementaciones siempre tienen una dependencia automática en el módulo padre el cual les proporciona acceso a las clases en el directorio EAR/lib/. Sin embargo, las subimplementaciones no siempre tienen una dependencia automática para permitirles el acceso entre ellas. Este comportamiento se controla configurando el elemento <ear-subdeployments-isolated> en la configuración del subsistema ee así:

   <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
     <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
   </subsystem>
   

   Por defecto esto se configura como falso, lo cual permite que las subimplementaciones vean las clases que pertenecen a otras subimplementaciones dentro del EAR.
   Para mayor información sobre la carga de clases consulte al capítulo titulado Módulos y carga de clases en la Guía de desarrollo para JBoss EAP 6 en https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

1. Si su aplicación usa una fuente de datos consulte: Sección 3.1.6.2, “Actualización de la configuración de la fuente de datos”.

2. Si su aplicación usa JPA y actualmente une las JARs Hibernate consulte lo siguiente para ver sus opciones de migración: Sección 3.1.6.4, “Configuración de la fuente de datos para Hibernate o JPA”.
3. Si su aplicación usa un adaptador de recursos consulte: Sección 3.1.6.5, “Actualización de la configuración del adaptador de recursos”.
4. Revise lo siguiente para obtener mayor información sobre cómo configurar los cambios para la seguridad básica: Sección 3.1.7.1, “Configuración de los cambios de seguridad de la aplicación”.

Procedimiento 3.8. Instalación y configuración del controlador JDBC

1. Instalación del controlador JDBC

   1. Instalación del controlador JDBC como implementación

      Esta es la manera recomendada de instalar el controlador. Cuando el controlador JDBC se instala como una implementación, se implementa como una JAR normal. Si la instancia de JBoss EAP 6 está ejecutando como un servidor autónomo, copie la JAR que cumple con los requerimientos de JDBC 4.0 en el directorio EAP_HOME/standalone/deployments/. Si el servidor está ejecutando en un dominio administrado, copie la JAR en el directorio EAP_HOME/domain/deployments/.
      El siguiente es un ejemplo de un controlador MySQL JDBC instalado como una implementación en un servidor autónomo:

      $cp mysql-connector-java-5.1.15.jar EAP_HOME/standalone/deployments/

      Cualquier controlador que cumple con los requerimientos de JDBC 4.0 es reconocido automáticamente y se instala en el sistema por nombre y versión. Una JAR que cumple con los requerimientos de JDBC 4.0 contiene un archivo de texto llamado META-INF/services/java.sql.Driver, el cual especifica los nombres de las clases controladoras. Si el controlador no cumple con los requerimientos de JDBC 4.0 entonces se puede hacer que se implemente de una de las siguientes maneras:

      • Cree y agregue un archivo java.sql.Driver a la JAR bajo la ruta META-INF/services/. Este archivo debe contener el nombre de la clase del controlador, por ejemplo:

        com.mysql.jdbc.Driver

      • Cree un archivo java.sql.Driver en el directorio de implementaciones. Para una instancia de JBoss EAP 6 ejecutando como un servidor autónomo, el archivo se debe poner aquí: EAP_HOME/standalone/deployments/META-INF/services/java.sql.Driver. Si el servidor está en un dominio administrado, el archivo se debe poner aquí: EAP_HOME/domain/deployments/META-INF/services/java.sql.Driver.
      Las ventajas de este enfoque son:

      • Este es el método más fácil ya que no hay necesidad de definir un módulo.
      • Cuando el servidor está ejecutando en un dominio administrado, las implementaciones que usan este enfoque se propagan de manera automática en todos los servidores en el dominio. Esto significa que el administrador no necesita distribuir el controlador JAR manualmente.

      Las desventajas de este enfoque son:

      • Si el controlador JDBC consiste de mas de una JAR, por ejemplo el controlador JAR más una licencia JAR dependiente o una JAR de localización, no puede instalar el controlador como una implementación. Tiene que instalar el controlador JDBC como un módulo núcleo.
      • Si el controlador no cumple con los requerimientos de JDBC 4.0 entonces se debe crear un archivo que contenga los nombres de las clases controladoras y tiene que ser importado en la JAR o superpuesto en el directorio deployments/.

   2. Instalación del controlador JDBC como módulo central

      Para instalar un controlador JDBC como un módulo núcleo, tiene que crear una estructura de ruta de archivos bajo el directorio EAP_HOME/modules/. Esta estructura contiene la JAR del controlador JDBC, las JARS de localización o las licencias adicionales del vendedor y un archivo module.xml para definir el módulo.

      • Instale el controlador MySQL JDBC como módulo núcleo

        1. Cree la estructura del directorio EAP_HOME/modules/com/mysql/main/
        2. En el subdirectorio main/, cree un archivo module.xml que contenga la siguiente definición de módulo para el controlador MySQL JDBC:

           <?xml version="1.0" encoding="UTF-8"?>
           <module xmlns="urn:jboss:module:1.0" name="com.mysql">
           <resources>
               <resource-root path="mysql-connector-java-5.1.15.jar"/>
           </resources>
           <dependencies>
               <module name="javax.api"/>
           </dependencies>
           </module>
           
           
           

           El nombre del módulo, "com.mysql", coincide con la estructura del directorio para este módulo. El elemento <dependencies> se usa para especificar las dependencias de este módulo en otros módulos. En este caso, tal como los es con todas las fuentes de datos JDBC, depende de las APIs JDBC Java que se definen en otro módulo llamado javax.api. Ese módulo se encuentra bajo el directorio modules/system/layers/base/javax/api/main/.

           Nota

           Asegúrese de NO tener un espacio al principio del archivo module.xml de otra manera obtendrá un error "New missing/unsatisfied dependencies" para este controlador.
        3. Copie la JAR del controlador MySQL JDBC en el directorio EAP_HOME/modules/com/mysql/main/:

           $ cp mysql-connector-java-5.1.15.jar EAP_HOME/modules/com/mysql/main/

      • Instale el controlador IBM DB2 JDBC y la JAR licencia como un módulo núcleo

        Este ejemplo se proporciona sólo para demostrar la manera de implementar controladores que requieren JARs además de la JAR del controlador JDBC.
        1. Cree la estructura del directorio EAP_HOME/modules/com/ibm/db2/main/.
        2. En el subdirectorio main/, cree un archivo module.xml que contenga la siguiente definición de módulo para el controlador IBM DB2 JDBC y licencia:

           <?xml version="1.0" encoding="UTF-8"?>
           <module xmlns="urn:jboss:module:1.1" name="com.ibm.db2">
             <resources>
               <resource-root path="db2jcc.jar"/>
               <resource-root path="db2jcc_license_cisuz.jar"/>
             </resources>
             <dependencies>
               <module name="javax.api"/>
               <module name="javax.transaction.api"/>
             </dependencies>
           </module>
           
           

           Nota

           Asegúrese de NO tener un espacio al principio del archivo module.xml de otra manera obtendrá un error "New missing/unsatisfied dependencies" para este controlador.
        3. Copie el controlador JDBC y la JAR de lincencia en el directorio EAP_HOME/modules/com/ibm/db2/main/.

           $ cp db2jcc.jar EAP_HOME/modules/com/ibm/db2/main/
           $ cp db2jcc_license_cisuz.jar EAP_HOME/modules/com/ibm/db2/main/

      Las ventajas de este enfoque son:

      • Este es el único enfoque que funciona cuando el controlador JDBC consiste de más de una JAR.
      • Con este enfoque, los controladores que no cumplen con los requerimientos de JDBC 4.0 se pueden instalar sin modificar la JAR del controlador o creando una superposición de archivos.

      Las desventajas de este enfoque son:

      • Es más dificil configurar un módulo.
      • El módulo se debe copiar manualmente en todos los servidores ejecutando en un dominio administrado.

2. Configuración de la fuente de datos

   1. Agregar el controlador de la base de datos

      Agregar el elemento <driver> al elemento <drivers> del mismo archivo. Nuevamente esto contiene alguna de la misma información de la fuente de datos que se definió previamente en el archivo *-ds.xml.
      Primero determine si la JAR controladora cumple con los requerimientos de JDBC 4.0. Una JAR que cumple con los requerimientos de JDBC 4.0 contiene un archivo META-INF/services/java.sql.Driver que especifica el nombre de la clase controladora. El servidor usa este archivo para encontrar el nombre de las clases controladoras en la JAR. Un controlador que cumpla con los requerimientos de JDBC 4.0 no requiere un elemento <driver-class> ya que ya se especifica en la JAR. Este es un ejemplo del elemento controlador para un controlador MySQL que cumple con los requerimientos de JDBC 4.0:

      <driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"/>
      

      Un controlador que no cumple con los requerimientos de JDBC 4.0 requiere un atributo <driver-class> para identificar la clase del controlador ya que no hay un archivo META-INF/services/java.sql.Driver que especifique el nombre de la clase controladora. Este es un ejemplo del elemento controlador para el controlador que no cumpla con los requerimientos de JDBC 4.0:

      <driver name="mysql-connector-java-5.1.15.jar" module="com.mysql"><driver-class>com.mysql.jdbc.Driver</driver-class></driver>
      
      

   2. Creación de la fuente de datos

      Cree un elemento <datasource> en la sección <datasources> del archivo standalone.xml. Este archivo contiene mucha de las misma información de la fuente de datos que se definió anteriormente en el archivo *-ds.xml.

      Importante

      Tiene que detener el servidor antes de modificar el archivo de configuración del servidor para que su cambio persista al reiniciar el servidor.
      El siguiente es un ejemplo de un elemento de la fuente de datos MySQL en el archivo standalone.xml:

      <datasource jndi-name="java:/YourDatasourceName" pool-name="YourDatasourceName">
        <connection-url>jdbc:mysql://localhost:3306/YourApplicationURL</connection-url>
        <driver>mysql-connector-java-5.1.15.jar</driver>
        <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
        <pool>
          <min-pool-size>100</min-pool-size>
          <max-pool-size>200</max-pool-size>
        </pool>
        <security>
          <user-name>USERID</user-name>
          <password>PASSWORD</password>
        </security>
        <statement>
          <prepared-statement-cache-size>100</prepared-statement-cache-size>
          <share-prepared-statements/>
        </statement>
      </datasource>
      
      

Procedimiento 3.9. Borre el paquete Hibernate

1. Borre las JARs Hibernate de sus carpetas de la biblioteca de su aplicación.

2. Borre o comente el elemento <hibernate.transaction.manager_lookup_class> en su archivo persistence.xml ya que este elemento no se necesita.

Procedimiento 3.10. Modificar búsquedas JNDI

1. Mayor información sobre Sección 3.1.8.2, “Nombres JNDI EJB portátiles”

2. Sección 3.1.8.3, “Revisión de las reglas del espacio de nombres de JNDI”
3. Sección 3.1.8.4, “Modifique la aplicación a seguir las nuevas reglas de los espacios de nombre JNDI”

Procedimiento 3.11.

1. Sección 3.2.2.2, “Configuración de cambios para las aplicaciones que usan Hibernate y JPA”

2. Sección 3.2.2.4, “Actualización de su aplicación Hibernate 3 para utilizar Hibernate 4”

3. Sección 3.2.2.9, “Actualización de su aplicación para que cumpla con los requerimientos de la especificación JPA 2.0”

4. Sección 3.2.2.10, “Reemplace el caché de segundo nivel JPA/Hibernate con Infinispan”

5. Sección 3.2.2.12, “Migración a Hibernate Validator 4”

Procedimiento 3.12. Configure la aplicación

1. Copie las JARs Hibernate 3 requeridas en su biblioteca de aplicaciones.

   Es posible que resuelva el problema copiando las JARs específicas de Hibernate 3 que contengan las clases que faltan en el directorio lib/ de la aplicación o agregándolas a la ruta de clases usando algún otro método. En algunos casos esto puede generar ClassCastExceptions u otros problemas de carga de clases debido al uso mezclado de las versiones de Hibernate. Si eso sucede entonces necesita usar el siguiente enfoque.

2. Ordénele al servidor el utilizar sólamente bibliotecas Hibernate 3.

   JBoss EAP 6 le permite empacar las jars del proveedor de persistencia Hibernate 3.5 (o posteriores) con la aplicación. Para ordenarle al servidor que use solamente las bibliotecas Hibernate 3 y excluir las bibliotecas Hibernate 4 necesita establecer el jboss.as.jpa.providerModule como hibernate3-bundled en el persistence.xml así:

   <?xml version="1.0" encoding="UTF-8"?>
   <persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
       <persistence-unit name="plannerdatasource_pu">
           <description>Hibernate 3 Persistence Unit.</description>
           <jta-data-source>java:jboss/datasources/PlannerDS</jta-data-source>
           <properties>
               <property name="hibernate.show_sql" value="false" />
               <property name="jboss.as.jpa.providerModule" value="hibernate3-bundled" />
           </properties>
       </persistence-unit>
   </persistence>
   
   

   El implementador JPA (Java Persistence API) detectará la presencia de un proveedor de persistencia en la aplicación y usa las bibliotecas Hibernate 3. Para mayor información sobre las propiedades de persistencia JPA, consulte Sección 3.2.2.3, “Propiedades de la unidad de persistencia”.

3. Inhabiltar el caché de segundo nivel de Hibernate

   El caché de segundo nivel para Hibernate 3 no presenta el mismo comportamiento con JBoss EAP 6 tal como lo hizo en lanzamientos anteriores. Si está utilizando el caché de segundo nivel de Hibernate con su aplicación, tiene que inhabilitarlo hasta que actualice a Hibernate 4. Para inhabilitar el caché de segundo nivel configure el <hibernate.cache.use_second_level_cache> como false en el archivo persistence.xml.

Procedimiento 3.13. Actualización de la aplicación para utilizar Hibernate 4

1. El comportamiento predeterminado del generador de secuencias de autoincremento cambió en JBoss EAP 6. Para mayor información, consulte Sección 3.2.2.5, “Preservar el comportamiento existente del valor auto generado de la identidad de Hibernate”.
2. Determine la versión de Hibernate que la aplicación utiliza actualmente y seleccione el procedimiento de actualización correcto.
   • Sección 3.2.2.6, “Migración de su aplicación Hibernate 3.3.x a Hibernate 4.x”
   • Sección 3.2.2.7, “Migración de su aplicación Hibernate 3.5.x a Hibernate 4.x”
3. Consulte Sección 3.2.2.8, “Modificación de las propiedades de persistencia para las aplicaciones Hibernate y Seam migradas que ejecutan en un entorno con clústers” si planea ejecutar su aplicación en un entorno con clústers.

Procedimiento 3.14.

1. Mapeo de los tipos Hibernate text a JDBC LONGVARCHAR

   En versiones de Hibernate anteriores a 3.5, el tipo text se mapeaba a JDBC CLOB. Se agregó un nuevo tipo Hibernate, materialized_clob, en Hibernate 4 para mapear propiedades String Java a JDBC CLOB. Si su aplicación tiene propiedades configuradas como type="text" que se planean mapear a JDBC CLOB, tiene que hacer una de las siguientes:
   1. Si su aplicación usa archivos de mapeo hbm cambie la propiedad a type="materialized_clob".
   2. Si su aplicación usa anotaciones, debe reemplazar @Type(type = "text") con @Lob.

2. Revise el código para encontrar los cambios en los tipos de valor retornados

   Las proyeciones de criterios de agregación numéricos ahora retornan el mismo tipo de valor que sus contrapartes HQL. Por lo tanto, los tipos de retorno de las siguientes proyecciones en org.hibernate.criterion cambiaron.
   1. Debido a los cambios en CountProjection, Projections.rowCount(), Projections.count(propertyName) y Projections.countDistinct(propertyName), las proyecciones count y count distinct ahora retornan un valor Long.
   2. Debido a los cambios en Projections.sum(propertyName), las proyecciones sum ahora retornan un tipo de valor que depende del tipo de la propiedad.

      Nota

      Si no modifica el código de su aplicación se puede generar una java.lang.ClassCastException.
      1. Para las propiedades mapeadas como los tipos de números enteros primitivos, Long, Short o Integer se retorna una valor Long;
      2. Para las propiedades mapeadas como tipos de de punto flotante primitivo, Float o Double se retorna un valor Double.

Procedimiento 3.15.

1. Fusione AnnotationConfiguration en la configuración

   Aunque AnnotationConfiguration ya no se utiliza no debe afectar su migración.
   Si todavía está usando un archivo hbm.xml debe tener en cuenta de que JBoss EAP 6 ahora usa org.hibernate.cfg.EJB3NamingStrategy en AnnotationConfiguration en lugar de la org.hibernate.cfg.DefaultNamingStrategy que se utilizaba en lanzamientos anteriores. Esto puede generar coincidencias equivocadas en los nombres. Si depende de que la estrategia de nombrado use por defecto el nombre de una tabla de asociación (muchos-a-muchos y colecciones de elementos) entonces es posible que vea este problema. Para resolver este problema le puede decir a Hibernate que use la org.hibernate.cfg.DefaultNamingStrategy de legado llamando Configuration#setNamingStrategy y pasándole org.hibernate.cfg.DefaultNamingStrategy#INSTANCE.

2. Modifique los espacios de nombres para que cumplan con los requerimientos de los nuevos nombres de los archivos Hibernate DTD.

   Tabla 3.5.

   Espacio de nombre DTD anterior	Nuevo espacio de nombre DTD
   http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd	http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd
   http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd	http://www.hibernate.org/dtd/hibernate-mapping-3.0.dtd

3. Modificar las variables del entorno

   1. Si está usando Oracle y usando las propiedades materialized_clob o materialized_blob entonces la variable global del entorno hibernate.jdbc.use_streams_for_binary se debe configurar como verdadera.
   2. Si está usando PostgreSQL y las propiedades CLOB or BLOB entonces la variable global del entorno hibernate.jdbc.use_streams_for_binary se debe configurar como falsa.

Procedimiento 3.16. Configure las propiedades de persistencia para ejecutar en un entorno con clústers

1. Establezca el valor hibernate.session_factory_name con un nombre único. Este nombre debe ser único a través de todas las implementaciones de la aplicación en la instancia de JBoss EAP 6. Por ejemplo:

   <property name="hibernate.session_factory_name" value="jboss-seam-booking.ear_session_factory"/>
   
   

2. Establezca el valor hibernate.ejb.entitymanager_factory_name con un nombre único. Este nombre debe ser único a través de todas las implementaciones de la aplicación en la instancia de JBoss EAP 6. Por ejemplo:

   <property name="hibernate.ejb.entitymanager_factory_name" value="seam-booking.ear_PersistenceUnitName"/>
   
   

Procedimiento 3.17. Modifique el archivo persistence.xml para usar Infinispan

1. Configure Infinispan para una aplicación JPA en JBoss EAP 6

   Esta es la manera de especificar propiedades para lograr la misma configuración para una aplicación JPA usando Infinispan en JBoss EAP 6:

   <property name="hibernate.cache.use_second_level_cache" value="true"/>
   
   

   Además necesita especificar un shared-cache-mode con el valor de ENABLE_SELECTIVE o ALL así:
   • ENABLE_SELECTIVE es el valor predeterminado y recomendado. Significa que las entidades ya no se ponen en el caché a menos de que las marque explícitamente como para usar el caché.

     <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
     
     

   • ALL significa que las entidades siempre se ponen en el caché incluso si las marca para no ponerlas en el caché.

     <shared-cache-mode>ALL</shared-cache-mode>
     
     

2. Configure Infinispan para una aplicación Hibernate nativa en JBoss EAP 6

   Esta es la manera de especificar la misma configuración para una aplicación nativa Hibernate usando Infinispan con JBoss EAP 6:

   <property name="hibernate.cache.region.factory_class"
        value="org.jboss.as.jpa.hibernate4.infinispan.InfinispanRegionFactory"/>
   <property name="hibernate.cache.infinispan.cachemanager"
        value="java:jboss/infinispan/container/hibernate"/>     
   <property name="hibernate.transaction.manager_lookup_class"
        value="org.hibernate.transaction.JBossTransactionManagerLookup"/>
   <property name="hibernate.cache.use_second_level_cache" value="true"/>
   
   
   

   También tiene que agregar las siguientes dependencias al archivo MANIFEST.MF:

   Manifest-Version: 1.0
   Dependencies: org.infinispan, org.hibernate
   

Procedimiento 3.18. Es posible que tenga que realizar una o más de las siguientes tareas

1. Acceder el ValidatorFactory predeterminado

   JBoss EAP 6 enlaza un ValidatorFactory predeterminado al contexto JNDI bajo el nombre java:comp/ValidatorFactory.

2. Comprender la validación disparada del ciclo de vida

   Cuando se utiliza junto con Hibernate Core 4, Hibernate Core habilita automáticamente la validación basada en el ciclo de vida.

   1. La validación ocurre en las operaciones de las entidades INSERT, UPDATE y DELETE operations.

   2. Puede configurar los grupos a validarse por tipo de evento usando las siguientes propiedades:

      • javax.persistence.validation.group.pre-persist,
      • javax.persistence.validation.group.pre-update y
      • javax.persistence.validation.group.pre-remove.

      Los valores de estas propiedades son los nombres de las clases completamente calificadas de los grupos a validar.
      Los grupos de validación son una nueva funcionalidad de la especificación de la validación de beans. Si no quiere tomar ventaja de esta nueva funcionalidad, no necesita realizar cambios cuando migre a Hibernate Validator 4.
   3. Puede inhabilitar la validación basada en el ciclo de vida configurando la propiedad javax.persistence.validation.mode como none. Los otros valores válidos para esta propiedad son auto (predeterminado), callback y ddl.

3. Configure su aplicación para usar la validación manual

   1. Si quiere controlar manualmente la validación, puede crear un validador de una de las siguientes maneras:

      • Cree una instancia Validator de la ValidatorFactory usando el método getValidator().
      • Las instancias del validador de inyección en su EJB, bean CDI o cualquier otro recurso Java EE inyectable.
   2. Puede utilizar el ValidatorContext retornado por el ValidatorFactory.usingContext() para personalizar la instancia de su validador. Usando esta API puede configurar un MessageInterpolator, TraverableResolver y ConstraintValidatorFactory personalizados. Estas interfaces se especifican en la especificación de la validación del bean y son nuevas para Hibernate Validator 4.

4. Modifique el código para utilizar las nuevas restricciones de validación del bean

   Las nuevas restricciones de validación a nivel del bean requieren cambios en el código cuando migra a Hibernate Validator 4.

   1. Para actualizar un Hibernate Validator 4, tiene que usar las restricciones en los siguientes paquetes:

      • javax.validation.constraints
      • org.hibernate.validator.constraints
   2. Todas las restricciones que existían en Hibernate Validator 3 todavía están disponibles en Hibernate Validator 4. Para utilizarlas necesita importar la clase especificada y en algunos casos, cambiar el nombre o tipo del parámetro de restricción.

5. Utilizar restricciones personalizadas

   En Hibernate Validator 3, una restricción personalizada necesitaba implementar la interfaz org.hibernate.validator.Validator. En Hibernate Validator 4, necesita implementar la interfaz javax.validation.ConstraintValidator. Esta interfaz contiene los mismo métodos initialize() and isValid() que la interfaz anterior, sin embargo, la firma del método cambió. Además, la modificación DDL ya no se soporta en Hibernate Validator 4.

Procedimiento 3.19. Configuración del puente JMS implementado en un servidor JBoss EAP 5.x

1. Cree un subdirectorio en el directorio de implementación de JBoss EAP 5 a contener el SAR, por ejemplo: EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar.
2. Cree un subdirectorio llamado META-INF en EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/.
3. Cree un archivo jboss-service.xml que contiene información similar al siguiente en el directorio EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/META-INF/.

   <server>
      <loader-repository>
         com.example:archive=unique-archive-name
         <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
      </loader-repository> 
   
      <!-- JBoss EAP 6 JMS Provider --> 
      <mbean code="org.jboss.jms.jndi.JMSProviderLoader" name="jboss.messaging:service=JMSProviderLoader,name=EnterpriseApplicationPlatform6JMSProvider">
         <attribute name="ProviderName">EnterpriseApplicationPlatform6JMSProvider</attribute>
         <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
         <attribute name="FactoryRef">jms/RemoteConnectionFactory</attribute> 
         <attribute name="QueueFactoryRef">jms/RemoteConnectionFactory</attribute>  
         <attribute name="TopicFactoryRef">jms/RemoteConnectionFactory</attribute>      
         <attribute name="Properties">
            java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
            java.naming.provider.url=remote://EnterpriseApplicationPlatform6host:4447
            java.naming.security.principal=jbossuser
            java.naming.security.credentials=jbosspass
         </attribute>
      </mbean> 
   
      <mbean code="org.jboss.jms.server.bridge.BridgeService" name="jboss.jms:service=Bridge,name=MyBridgeName" xmbean-dd="xmdesc/Bridge-xmbean.xml">      
         <depends optional-attribute-name="SourceProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends>          
         <depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=EnterpriseApplicationPlatform6JMSProvider</depends>          
         <attribute name="SourceDestinationLookup">/queue/A</attribute>      
         <attribute name="TargetDestinationLookup">jms/queue/test</attribute>       
         <attribute name="QualityOfServiceMode">1</attribute>           
         <attribute name="MaxBatchSize">1</attribute>      
         <attribute name="MaxBatchTime">-1</attribute>           
         <attribute name="FailureRetryInterval">60000</attribute>      
         <attribute name="MaxRetries">-1</attribute>      
         <attribute name="AddMessageIDInHeader">false</attribute>
         <attribute name="TargetUsername">jbossuser</attribute>
         <attribute name="TargetPassword">jbosspass</attribute>
      </mbean>
   </server>
           
   
   

   Nota

   El <load-repository> está presente para asegurar que el SAR tiene un cargador de clases aislado. También note que la búsqueda JNDI y el puente "destino" incluyen credenciales de seguridad para el usuario "jbossuser" con la contraseña "jbosspass". Esto se debe a que JBoss EAP 6 está asegurada por defecto. El usuario llamado "jbossuser" con contraseña "jbosspass" se creó en el ApplicationRealm con el rol guest usando el script EAP_HOME/bin/add_user.sh.
4. Copie las siguientes JARs del directorio EAP_HOME/modules/system/layers/base/ en el directorio EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/. Reemplace cada VERSION_NUMBER con el número de la versión en su distribución de JBoss EAP 6.

   • org/hornetq/main/hornetq-core-VERSION_NUMBER.jar
   • org/hornetq/main/hornetq-jms-VERSION_NUMBER.jar
   • org/jboss/ejb-client/main/jboss-ejb-client-VERSION_NUMBER.jar
   • org/jboss/logging/main/jboss-logging-VERSION_NUMBER.jar
   • org/jboss/logmanager/main/jboss-logmanager-VERSION_NUMBER.jar
   • org/jboss/marshalling/main/jboss-marshalling-VERSION_NUMBER.jar
   • org/jboss/marshalling/river/main/jboss-marshalling-river-VERSION_NUMBER.jar
   • org/jboss/remote-naming/main/jboss-remote-naming-VERSION_NUMBER.jar
   • org/jboss/remoting3/main/jboss-remoting-VERSION_NUMBER.jar
   • org/jboss/sasl/main/jboss-sasl-VERSION_NUMBER.jar
   • org/jboss/netty/main/netty-VERSION_NUMBER.jar
   • org/jboss/remoting3/remote-jmx/main/remoting-jmx-VERSION_NUMBER.jar
   • org/jboss/xnio/main/xnio-api-VERSION_NUMBER.jar
   • org/jboss/xnio/nio/main.xnio-nio-VERSION_NUMBER.jar

   Nota

   No copie simplemente EAP_HOME/bin/client/jboss-client.jar ya que las clases API javax entrarán en conflicto con las de JBoss EAP JBoss 5.x.

Procedimiento 3.20. Configuración del puente JMS implementado en un servidor JBoss EAP 6.x

1. Cree el módulo JBoss para el proveedor de mensajería.
   1. Cree una estructura de directorio bajo EAP_HOME/modules/system/layers/base/ para el nuevo módulo. El subdirectorio main/ tendrá las JARs clientes y el archivo module.xml. El siguiente es un ejemplo de la estructura de directorio creada para el proveedor de mensajería MyCustomMQ: EAP_HOME/modules/system/layers/base/org/mycustommq/main/
   2. En el subdirectorio main/ cree un archivo module.xml que contenga la definición del módulo para el proveedor de mensajería. El siguiente es un ejemplo del module.xml creado para el proveedor de mensajería MyCustomMQ.

      <?xml version="1.0" encoding="UTF-8"?>
      <module xmlns="urn:jboss:module:1.1" name="org.mycustommq">
          <properties>
              <property name="jboss.api" value="private"/>
          </properties> 
      
          <resources>
              <!-- Insert resources required to connect to the source or target   -->
              <resource-root path="mycustommq-1.2.3.jar" />
              <resource-root path="mylogapi-0.0.1.jar" />
          </resources> 
      
          <dependencies>
             <!-- Add the dependencies required by JMS Bridge code                 -->
             <module name="javax.api" />
             <module name="javax.jms.api" />
             <module name="javax.transaction.api"/>
             <!-- Add a dependency on the org.hornetq module since we send         -->
             <!-- messages tothe HornetQ server embedded in the local EAP instance -->
             <module name="org.hornetq" />
          </dependencies>
      </module>
      
      

   3. Copie las JARs del proveedor de mensajería requeridas para la búsqueda JNDI de los recursos fuente en el subdirectorio main/ del módulo. La estructura del directorio para el módulo MyCustomMQ ahora se debe ver como la siguiente.

      modules/
      `-- system
          `-- layers
              `-- base
                  `-- org
                        `-- mycustommq
                            `-- main
                                |-- mycustommq-1.2.3.jar
                                |-- mylogapi-0.0.1.jar
                                |-- module.xml
      

2. Configuración del puente JMS en el subsistema messaging del servidor JBoss EAP 6.
   1. Antes de empezar, detenga el servidor y relice una copia de seguridad de los archivos de configuración del servidor. Si está ejecutando un servidor autónomo este es el archivo EAP_HOME/standalone/configuration/standalone-full-ha.xml. Si está ejecutando un dominio administrado, realice una copia de seguridad de los archivos EAP_HOME/domain/configuration/domain.xml y EAP_HOME/domain/configuration/host.xml.
   2. Agregue el elemento <jms-bridge> al subsistema messaging en el archivo de configuración del servidor. Los elementos <source> y <target> proporciona los nombres de los recursos JMS utilizados para búsquedas JNDI. Si se especifican las credenciales <user> y <password> entonces se pasan como argumentos cuando se crea una conexión JMS.
      El siguiente es un ejemplo del elemento <jms-bridge> configurado para el proveedor de mensajería MyCustomMQ:

      <subsystem xmlns="urn:jboss:domain:messaging:1.3">
         ...
         <jms-bridge name="myBridge" module="org.mycustommq">
            <source>
               <connection-factory name="ConnectionFactory"/>
               <destination name="sourceQ"/>
               <user>user1</user>
               <password>pwd1</password>
               <context>
                  <property key="java.naming.factory.initial" value="org.mycustommq.jndi.MyCustomMQInitialContextFactory"/>
                  <property key="java.naming.provider.url"    value="tcp://127.0.0.1:9292"/>
               </context>
            </source>
            <target>
               <connection-factory name="java:/ConnectionFactory"/>
               <destination name="/jms/targetQ"/>
            </target>
            <quality-of-service>DUPLICATES_OK</quality-of-service>
            <failure-retry-interval>500</failure-retry-interval>
            <max-retries>1</max-retries>
            <max-batch-size>500</max-batch-size>
            <max-batch-time>500</max-batch-time>
            <add-messageID-in-header>true</add-messageID-in-header>
         </jms-bridge>
      </subsystem>
      
      

      En el ejemplo anterior, las propiedades JNDI se definen en el elemento <context> para la <source>. Si se omite el elemento <context> como en el ejemplo anterior <target> entonces los recursos JMS se buscan en la instancia local.

Procedimiento 3.21. Antes de iniciar

1. Apague el cliente y el servidor.
2. Realice una copia de seguridad de los datos de JBoss Messaging. Los datos del mensaje se almacenan en tablas con el prefijo JBM_.

Procedimiento 3.22. Cambie su proveedor a HornetQ

1. Transferencia de configuraciones

   Transfiera las configuraciones existentes de JBoss Messaging a la configuración de JBoss EAP 6. Las siguientes configuraciones se pueden encontrar en los descriptores de implementación que se encuentran en el servidor de mensajería de JBoss:
   • Configuración del servicio de fábricas de conexiones
     Esta configuración describe las fábricas de conexiones JMS implementadas con el servidor JBoss Messaging. JBoss Messaging configura las fábricas de conexiones en un archivo llamado connection-factories-service.xml, el cual se encuentra en el directorio de implementación del servidor de aplicaciones.
   • Configuración de destino
     Esta configuración describe colas y temas JMS implementadas con el servidor JBoss Messaging. Por defecto, JBoss Messaging configura destinos en un archivo llamado destinations-service.xml, el cual se encuentra en el directorio de implementación del servidor de aplicaciones.
   • Configuración del servicio de puente de mensajes
     Esta configuración incluye los servicios de puente implementados con el servidor JBoss Messaging. Por defecto no se implementa ningún puente así que el nombre del archivo de implementación varía dependiendo de su instalación JBoss Messaging.

2. Modificación de su código de aplicación

   Si el código de la aplicación usa JMS estándar, no se requieren cambios en el código. Sin embargo, si la aplicación se estará conectando a un clúster tiene que revisar cuidadosamente la documentación de HornetQ con relación a la semántica de los clústers. Los clústers están por fuera del ámbito de la especificación JMS y HornetQ y JBoss Messaging han tomado diferentes enfoques en sus respectivas implementaciones de la funcionalidad de clústers.
   Si la aplicación usa funcionalidades específicas para JBoss Messaging, tiene que modificar el código para utilizar las funcionalidades equivalentes disponibles en HornetQ.
   Para mayor información sobre cómo configurar la mensajería con HornetQ, consulte: Sección 3.2.7.4, “Configuración de la mensajería con HornetQ”

3. Migrar los mensajes existentes

   Mueva los mensajes que estén en la base de datos JBoss Messaging al diario HornetQ usando un puente JMS. Puede encontrar las instrucciones para configurar el puente JMS aquí: Sección 3.2.7.2, “Configuración de un puente JMS para migrar mensajes JMS existentes a JBoss EAP 6”.

Procedimiento 3.23.

1. Inicie JBoss EAP 6 con el uso de clústers habilitado

   Para habilitar el uso de clústers en JBoss EAP 5.x, necesitaba iniciar sus instancias del servidor usando el perfil all o alguna derivación de este así:
   $ EAP5_HOME/bin/run.sh -c all
   En JBoss EAP 6, el método para habilitar el clúster depende de si los servidores son autónomos o si están ejecutando en un dominio administrado.

   1. Habilite el clúster para los servidores ejecutando en un dominio administrado

      Para habilitar el uso de clústers para los servidores iniciados usando el controlador de dominio, actualice su domain.xml y designe un grupo de servidores para utilizar el perfil ha y el grupo de enlace de sockets ha-sockets. Por ejemplo:

      <server-groups>
        <server-group name="main-server-group" profile="ha">
          <jvm name="default">
            <heap size="64m" max-size="512m"/>
          </jvm>
          <socket-binding-group ref="ha-sockets"/>
        </server-group>
      </server-group>
      

   2. Habilitación del uso de clústers para servidores autónomos

      Para habilitar los clústers para los servidores autónomos inicie el servidor usando el archivo de configuración apropiado así: $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME

2. Especifique la dirección de enlace

   En JBoss EAP 5.x usualmente indicaría la dirección de enlace utilizada para el uso de clústers utilizando el argumento de la línea de comandos -b así: $ EAP_HOME/bin/run.sh -c all -b 192.168.0.2
   En JBoss EAP 6, las direcciones de enlace se definen explícitamente por los enlaces de socket relevantes dentro de los archivos de configuración de JBoss EAP 6. Para los servidores iniciados usando el controlador de dominios, las direcciones de enlace se especifican dentro del archivo domain/configuration/host.xml. Para los servidores autónomos las direcciones de enlace se especifican dentro del archivo standalone-ha.xml:

   <interfaces>
     <interface name="management">
       <inet-address value="192.168.0.2"/>
         </interface>
         <interface name="public">
       <inet-address value="192.168.0.2"/>
     </interface>
   </interfaces>
   

   <socket-binding-groups>
     <socket-binding-group name="ha-sockets" default-interface="public">
       <!-- ... -->
     </socket-binding-group>
   </socket-binding-groups>
   

   En el ejemplo anterior, la interfaz public se especifica como la interfaz predeterminada para todos los sockets dentro del grupo de enlace del socket ha-sockets.

3. Configure jvmRoute para soportar mod_jk y mod_proxy

   En JBoss EAP 5, el servidor web jvmRoute se configuraba usando una propiedad en el archivo server.xml. En JBoss EAP 6, el atributo jvmRoute se configura en el subsistema web del archivo de configuración del servidor usando el atributo instance-id así:

   <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false" instance-id="{JVM_ROUTE_SERVER}">
   
   

   El {JVM_ROUTE_SERVER} anterior se debe reemplazar por el id del servidor jvmRoute server.
   El instance-id también se puede configurar usando la consola de administración.

4. Especifique la dirección y puerto multicast

   En JBoss EAP 5.x puede especificar la dirección y puerto multicast utilizados para la comunicación interna del clúster usando los argumentos de la línea de comandos -u y -m, respectivamente así: $ EAP_HOME/bin/run.sh -c all -u 228.11.11.11 -m 45688
   En JBoss EAP 6, la dirección multicast y el puerto utilizado para la comunicación intra-clúster se definen por medio del enlace de socket referenciado por la pila del protocolo JGroups relevante así:

   <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
       <stack name="udp">
           <transport type="UDP" socket-binding="jgroups-udp"/>
           <!-- ... -->
       </stack>
   </subsystem>
   

   <socket-binding-groups>
       <socket-binding-group name="ha-sockets" default-interface="public">
           <!-- ... -->
           <socket-binding name="jgroups-udp" port="55200" multicast-address="228.11.11.11" multicast-port="45688"/>
           <!-- ... -->
       </socket-binding-group>
   </socket-binding-groups>
   
   

   Si prefiere especificar la dirección multicast y el puerto en la línea de comandos, puede definir la dirección multicast y los puertos como propiedades del sistema y luego usar esas propiedades en la línea de comandos cuando inicie el servidor. En el siguiente ejemplo, jboss.mcast.addr es el nombre de la variable para la dirección multicast y jboss.mcast.port es el nombre de la variable para el puerto.

   <socket-binding name="jgroups-udp" port="55200"
    multicast-address="${jboss.mcast.addr:230.0.0.4}" multicast-port="${jboss.mcast.port:45688}"/>
   
   

   Luego puede iniciar su servidor usando los siguientes argumentos de la línea de comandos: $ EAP_HOME/bin/domain.sh -Djboss.mcast.addr=228.11.11.11 -Djboss.mcast.port=45688

5. Use una pila opcional del protocolo

   En JBoss EAP 5.x, puede manipular la pila predeterminada del protocolo utilizada para todos los servicios de clúster usando la propiedad del sistema jboss.default.jgroups.stack. $ EAP_HOME/bin/run.sh -c all -Djboss.default.jgroups.stack=tcp
   En JBoss EAP 6, la pila predeterminada del protocolo es definida por el subsistema JGroups dentro de domain.xml o standalone-ha.xml:

   <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
       <stack name="udp">
           <!-- ... -->
       </stack>
   </subsystem>
   

6. Reemplazar la replicación de compañeros

   JBoss EAP 5.x utilizaba la replicación de compañeros de JBoss Cache para suprimir la réplica de datos en todas las instancias en un clúster. Se requería que pasara el argumento -Djboss.cluster.buddyRepl en la línea de comandos cuando iniciaba el servidor JBoss.
   En JBoss EAP 6, la replicación de compañeros fue reemplazada por el caché distribuído mucho mas superior de Infinispan o modo DIST. La distribución es un modo de uso de clústers poderoso el cual le permite a Infinispan el escalar linearmente cuando se agregan mas servidores al clúster. El siguiente es un ejemplo de cómo configurar el servidor para utilizar el modo de caché DIST.
   1. Abra una línea de comandos e inicie el servidor con el perfil HA o Full Profile, por ejemplo:

      EAP_HOME/bin/standalone.sh -c standalone-ha.xml

   2. Abra otra línea de comandos y conéctese al CLI de administración.
      • Para Linux, ingrese lo siguiente en la línea de comandos:

        $ EAP_HOME/bin/jboss-cli.sh --connect
        

      • Para Windows, ingrese lo siguiente en la línea de comandos:

        C:\>EAP_HOME\bin\jboss-cli.bat --connect
        

      Debe ver la siguiente respuesta:

      Conectado a un controlador autónomo en localhost:9999

   3. Emita los siguientes comandos:

      /subsystem=infinispan/cache-container=web/:write-attribute(name=default-cache,value=dist)
      /subsystem=infinispan/cache-container=web/distributed-cache=dist/:write-attribute(name=owners,value=3)
      :reload
      

      Debe ver la siguiente respuesta después de cada comando:

      "outcome" => "success"
      

      Estos comandos crean la siguiente configuración en el subsistema infinispan del archivo standalone-ha.xml:

      <cache-container name="web" aliases="standard-session-cache" default-cache="dist" module="org.jboss.as.clustering.web.infinispan">
          <transport lock-timeout="60000"/>
          <replicated-cache name="repl" mode="ASYNC" batching="true">
              <file-store/>
          </replicated-cache>
          <replicated-cache name="sso" mode="SYNC" batching="true"/>
          <distributed-cache name="dist" owners="3" l1-lifespan="0" mode="ASYNC" batching="true">
              <file-store/>
          </distributed-cache>
      </cache-container>
      
      

      Para mayor información consulte el capítulo titulado Clustering in Web Applications en la Development Guide para JBoss EAP 6 que se encuentra en el portal del cliente en https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

Procedimiento 3.24. Implementación de un servicio Singleton HA

1. Escriba la aplicación del servicio singleton HA.

   El siguiente es un ejemplo simple de un servicio que está envuelto con el decorador SingletonService a implementarse como un servicio singleton.

   1. Crear un servicio singleton.

      El siguiente listado es un ejemplo de un servicio singleton:

      package com.mycompany.hasingleton.service.ejb;
      
      import java.util.concurrent.atomic.AtomicBoolean;
      import java.util.logging.Logger;
      
      import org.jboss.as.server.ServerEnvironment;
      import org.jboss.msc.inject.Injector;
      import org.jboss.msc.service.Service;
      import org.jboss.msc.service.ServiceName;
      import org.jboss.msc.service.StartContext;
      import org.jboss.msc.service.StartException;
      import org.jboss.msc.service.StopContext;
      import org.jboss.msc.value.InjectedValue;
      
      /**
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      public class EnvironmentService implements Service<String> {
          private static final Logger LOGGER = Logger.getLogger(EnvironmentService.class.getCanonicalName());
          public static final ServiceName SINGLETON_SERVICE_NAME = ServiceName.JBOSS.append("quickstart", "ha", "singleton");
          /**
           * A flag whether the service is started.
           */
          private final AtomicBoolean started = new AtomicBoolean(false);
      
          private String nodeName;
      
          private final InjectedValue<ServerEnvironment> env = new InjectedValue<ServerEnvironment>();
      
          public Injector<ServerEnvironment> getEnvInjector() {
              return this.env;
          }
      
          /**
           * @return the name of the server node
           */
          public String getValue() throws IllegalStateException, IllegalArgumentException {
              if (!started.get()) {
                  throw new IllegalStateException("The service '" + this.getClass().getName() + "' is not ready!");
              }
              return this.nodeName;
          }
      
          public void start(StartContext arg0) throws StartException {
              if (!started.compareAndSet(false, true)) {
                  throw new StartException("The service is still started!");
              }
              LOGGER.info("Start service '" + this.getClass().getName() + "'");
              this.nodeName = this.env.getValue().getNodeName();
          }
      
          public void stop(StopContext arg0) {
              if (!started.compareAndSet(true, false)) {
                  LOGGER.warning("The service '" + this.getClass().getName() + "' is not active!");
              } else {
                  LOGGER.info("Stop service '" + this.getClass().getName() + "'");
              }
          }
      }
      
      

   2. Cree un singleton EJB para iniciar el servicio como un SingletonService al iniciar el servidor.

      El siguiente listado es un ejemplo de un singleton EJB que inicia un SingletonService al iniciar el servidor:

      package com.mycompany.hasingleton.service.ejb;
      
      import java.util.Collection;
      import java.util.EnumSet;
      
      import javax.annotation.PostConstruct;
      import javax.annotation.PreDestroy;
      import javax.ejb.Singleton;
      import javax.ejb.Startup;
      
      import org.jboss.as.clustering.singleton.SingletonService;
      import org.jboss.as.server.CurrentServiceContainer;
      import org.jboss.as.server.ServerEnvironment;
      import org.jboss.as.server.ServerEnvironmentService;
      import org.jboss.msc.service.AbstractServiceListener;
      import org.jboss.msc.service.ServiceController;
      import org.jboss.msc.service.ServiceController.Transition;
      import org.jboss.msc.service.ServiceListener;
      import org.slf4j.Logger;
      import org.slf4j.LoggerFactory;
      
      
      /**
       * A Singleton EJB to create the SingletonService during startup.
       * 
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      @Singleton
      @Startup
      public class StartupSingleton {
        private static final Logger LOGGER = LoggerFactory.getLogger(StartupSingleton.class);
      
        /**
         * Create the Service and wait until it is started.<br/>
         * Will log a message if the service will not start in 10sec. 
         */
        @PostConstruct
        protected void startup() {
          LOGGER.info("StartupSingleton will be initialized!");
      
          EnvironmentService service = new EnvironmentService();
          SingletonService<String> singleton = new SingletonService<String>(service, EnvironmentService.SINGLETON_SERVICE_NAME);
          // if there is a node where the Singleton should deployed the election policy might set,
          // otherwise the JGroups coordinator will start it
          //singleton.setElectionPolicy(new PreferredSingletonElectionPolicy(new NamePreference("node2/cluster"), new SimpleSingletonElectionPolicy()));
          ServiceController<String> controller = singleton.build(CurrentServiceContainer.getServiceContainer())
              .addDependency(ServerEnvironmentService.SERVICE_NAME, ServerEnvironment.class, service.getEnvInjector())
              .install();
      
          controller.setMode(ServiceController.Mode.ACTIVE);
          try {
            wait(controller, EnumSet.of(ServiceController.State.DOWN, ServiceController.State.STARTING), ServiceController.State.UP);
            LOGGER.info("StartupSingleton has started the Service");
          } catch (IllegalStateException e) {
            LOGGER.warn("Singleton Service {} not started, are you sure to start in a cluster (HA) environment?",EnvironmentService.SINGLETON_SERVICE_NAME);
          }
        }
      
        /**
         * Remove the service during undeploy or shutdown
         */
        @PreDestroy
        protected void destroy() {
          LOGGER.info("StartupSingleton will be removed!");
          ServiceController<?> controller = CurrentServiceContainer.getServiceContainer().getRequiredService(EnvironmentService.SINGLETON_SERVICE_NAME);
          controller.setMode(ServiceController.Mode.REMOVE);
          try {
            wait(controller, EnumSet.of(ServiceController.State.UP, ServiceController.State.STOPPING, ServiceController.State.DOWN), ServiceController.State.REMOVED);
          } catch (IllegalStateException e) {
            LOGGER.warn("Singleton Service {} has not be stopped correctly!",EnvironmentService.SINGLETON_SERVICE_NAME);
          }
        }
      
        private static <T> void wait(ServiceController<T> controller, Collection<ServiceController.State> expectedStates, ServiceController.State targetState) {
          if (controller.getState() != targetState) {
            ServiceListener<T> listener = new NotifyingServiceListener<T>();
            controller.addListener(listener);
            try {
              synchronized (controller) {
                int maxRetry = 2;
                while (expectedStates.contains(controller.getState()) && maxRetry > 0) {
                  LOGGER.info("Service controller state is {}, waiting for transition to {}", new Object[] {controller.getState(), targetState});
                  controller.wait(5000);
                  maxRetry--;
                }
              }
            } catch (InterruptedException e) {
              LOGGER.warn("Wait on startup is interrupted!");
              Thread.currentThread().interrupt();
            }
            controller.removeListener(listener);
            ServiceController.State state = controller.getState();
            LOGGER.info("Service controller state is now {}",state);
            if (state != targetState) {
              throw new IllegalStateException(String.format("Failed to wait for state to transition to %s.  Current state is %s", targetState, state), controller.getStartException());
            }
          }
        }
      
        private static class NotifyingServiceListener<T> extends AbstractServiceListener<T> {
          @Override
          public void transition(ServiceController<? extends T> controller, Transition transition) {
            synchronized (controller) {
              controller.notify();
            }
          }
        }
      }
      
      

   3. Cree un bean de sesión sin estado para acceder al servicio desde un cliente.

      El siguiente es un ejemplo de un bean de sesión sin estado que accede al servicio desde un cliente:

      package com.mycompany.hasingleton.service.ejb;
      
      import javax.ejb.Stateless;
      
      import org.jboss.as.server.CurrentServiceContainer;
      import org.jboss.msc.service.ServiceController;
      import org.slf4j.Logger;
      import org.slf4j.LoggerFactory;
      
      /**
       * A simple SLSB to access the internal SingletonService.
       * 
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      @Stateless
      public class ServiceAccessBean implements ServiceAccess {
          private static final Logger LOGGER = LoggerFactory.getLogger(ServiceAccessBean.class);
      
          public String getNodeNameOfService() {
              LOGGER.info("getNodeNameOfService() is called()");
              ServiceController<?> service = CurrentServiceContainer.getServiceContainer().getService(
                      EnvironmentService.SINGLETON_SERVICE_NAME);
              LOGGER.debug("SERVICE {}", service);
              if (service != null) {
                  return (String) service.getValue();
              } else {
                  throw new IllegalStateException("Service '" + EnvironmentService.SINGLETON_SERVICE_NAME + "' not found!");
              }
          }
      }
      
      

   4. Cree la interfaz de la lógica empresarial para el SingletonService.

      El siguiente es un ejemplo de una interfaz de lógica empresarial para el SingletonService:

      package com.mycompany.hasingleton.service.ejb;
      
      import javax.ejb.Remote;
      
      /**
       * Business interface to access the SingletonService via this EJB
       * 
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      @Remote
      public interface ServiceAccess {
          public abstract String getNodeNameOfService();
      } 
      
      
      

2. Inicie cada instancia de JBoss EAP 6 con el clúster habilitado.

   El método para habilitar el clúster depende de si los servidores son autónomos o ejecutando en un dominio administrado.

   1. Habilite el clúster para los servidores ejecutando en un dominio administrado.

      Puede habilitar el uso de clústers usando el CLI de administración o puede modificar manualmente el archivo de configuración.

      • Habilite el uso de clústers usando el CLI de administración.

        1. Inicie su controlador de dominios.

        2. Abra una ventana de comandos para su sistema operativo.

        3. Conéctese al CLI de administración pasando la dirección IP del controlador de dominio o el nombre DNS.

           En este ejemplo, asuma que la dirección IP del controlador de dominio es 192.168.0.14.
           • Para Linux, ingrese lo siguiente en la línea de comandos:

             $ EAP_HOME/bin/jboss-cli.sh --connect --controller=192.168.0.14
             

           • Para Windows, ingrese lo siguiente en la línea de comandos:

             C:\>EAP_HOME\bin\jboss-cli.bat --connect --controller=192.168.0.14
             

           Debe ver la siguiente respuesta:

           Conectado al controlador de dominio en 192.168.0.14

        4. Agregue el grupo del servidor main-server.

           [domain@192.168.0.14:9999 /] /server-group=main-server-group:add(profile="ha",socket-binding-group="ha-sockets") 
           {
               "outcome" => "success",
               "result" => undefined,
               "server-groups" => undefined
           }
           

        5. Cree un servidor llamado server-one y agréguelo al grupo de servidores main-server.

           [domain@192.168.0.14:9999 /]  /host=station14Host2/server-config=server-one:add(group=main-server-group,auto-start=false)
           {
               "outcome" => "success",
               "result" => undefined
           }
           

        6. Configure la MVJ para el grupo de servidores main-server.

           [domain@192.168.0.14:9999 /] /server-group=main-server-group/jvm=default:add(heap-size=64m,max-heap-size=512m)
           {
               "outcome" => "success",
               "result" => undefined,
               "server-groups" => undefined
           }
           

        7. Cree un servidor llamado server-two, póngalo en un grupo de servidores separado y configure la compensación del puerto como 100.

           [domain@192.168.0.14:9999 /]  /host=station14Host2/server-config=server-two:add(group=distinct2,socket-binding-port-offset=100)
           {
               "outcome" => "success",
               "result" => undefined
           }
           

      • Habilite el uso de clústers manualmente modificando los archivos de configuración del servidor.

        1. Detener el servidor JBoss EAP 6.

           Importante

           Tiene que detener el servidor antes de modificar el archivo de configuración del servidor para que su cambio persista al reiniciar el servidor.

        2. Abra el archivo de configuración domain.xml para modificar

           Designe un grupo de servidores para utilizar el perfil ha y el grupo de enlace de sockets ha-sockets así:

           <server-groups>
             <server-group name="main-server-group" profile="ha">
               <jvm name="default">
                 <heap size="64m" max-size="512m"/>
               </jvm>
               <socket-binding-group ref="ha-sockets"/>
             </server-group>
           </server-groups>
           
           

        3. Abra el archivo de configuración host.xml para modificar

           Modifique el archivo así:

           <servers>
             <server name="server-one" group="main-server-group" auto-start="false"/>
             <server name="server-two" group="distinct2">
               <socket-bindings port-offset="100"/>
             </server>
           <servers>
           
           

        4. Inicie el servidor.

           • Para Linux escriba: EAP_HOME/bin/domain.sh
           • Para Microsoft Windows escriba: EAP_HOME\bin\domain.bat

   2. Habilitación del uso de clústers para servidores autónomos

      Para habilitar el uso de clústers para servidores autónomos, inicie el servidor usando el nombre del nodo y el archivo de configuración standalone-ha.xml así:
      • Para Linux escriba: EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME
      • Para Microsoft Windows escriba: EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME

   Nota

   Para evitar conflictos de puertos al ejecutar múltiples servidores en una máquina, configure el archivo standalone-ha.xml para cada instancia del sevridor para enlazar en una interfaz separada. Opcionalmente, puede iniciar instancias del servidor posteriores con un offset del puerto usando un argumento como el siguiente en la línea de comandos: -Djboss.socket.binding.port-offset=100.

3. Implemente la aplicación en los servidores

   Si usa Maven para implementar su aplicación, use el siguiente comando Maven para implementar en el servidor ejecutando en los puertos predeterminados:
   mvn clean install jboss-as:deploy
   Para implementar en servidores adicionales, pase el nombre del servidor y el número del puerto en la línea de comandos:
   mvn clean package jboss-as:deploy -Ddeploy.hostname=localhost -Ddeploy.port=10099

Procedimiento 3.25. Agregación de la configuración del proyecto Maven para la invocación remota de beans de sesión

1. Agregar las dependencias requeridas del proyecto

   El pom.xml para el proyecto se debe actualizar para incluir las dependencias necesarias.

2. Agregue el archivo jboss-ejb-client.properties

   La API cliente EJB de JBoss espera encontrar un archivo en la raíz del proyecto llamado jboss-ejb-client.properties que contiene la información de la conexión para el servicio JNDI. Agregue este archivo al directorio src/main/resources/ de su proyecto con el siguiente contenido.

   # In the following line, set SSL_ENABLED to true for SSL
   remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
   remote.connections=default
   # Uncomment the following line to set SSL_STARTTLS to true for SSL
   # remote.connection.default.connect.options.org.xnio.Options.SSL_STARTTLS=true
   remote.connection.default.host=localhost
   remote.connection.default.port = 4447
   remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
   # Add any of the following SASL options if required
   # remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
   # remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false
   # remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
   
   

   Cambie el nombre del host y el puerto para que coincida con su servidor. 4447 es el número de puerto predeterminado. Para una conexión segura configure la línea SSL_ENABLED como true y borre el comentario de la línea SSL_STARTTLS. La interfaz remota en el contenedor soporta las conexiones seguras y no seguras usando el mismo puerto.

3. Agregar dependencias para las interfaces empresariales remotas

   Agregar las dependencias Maven al pom.xml para las interfaces empresariales remotas de los beans de sesión.

   <dependency>
      <groupId>org.jboss.as.quickstarts</groupId>
      <artifactId>jboss-as-ejb-remote-server-side</artifactId>
      <type>ejb-client</type>
      <version>${project.version}</version>
   </dependency>
   

Procedimiento 3.26. Obtenga un proxy bean usando JNDI e invoque métoodos del bean

1. Manejo de las excepciones verificadas

   Dos de los métodos usados en el siguiente código (InitialContext() y lookup()) tienen una excepción verificada del tipo javax.naming.NamingException. Estas llamadas de métodos pueden estar incluídas en un bloque try/catch que atrape NamingException o en un método que se declare para presentar NamingException. El manual de inicio rápido ejb-remote usa la segunda técnica.

2. Cree un contexto JNDI

   Un objeto del contexto JNDI proporciona el mecanismo para solicitar recursos del servidor. Cree un contexto JNDI usando el siguiente código:

   final Hashtable jndiProperties = new Hashtable();
   jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
   final Context context = new InitialContext(jndiProperties);
   

   Las propiedades de conexión para el servicio JNDI se leen del archivo jboss-ejb-client.properties.

3. Use el método lookup() del contexto JNDI para obtener un proxy bean

   Invoque el método lookup() del proxy bean y pásele el nombre JNDI del bean de sesión que requiera. Esto retornará un objeto que se debe vaciar al tipo de la interfaz empresarial remota que contiene los métodos que quiere invocar.

   
   final RemoteCalculator statelessRemoteCalculator = (RemoteCalculator) context.lookup(
       "ejb:/jboss-as-ejb-remote-server-side/CalculatorBean!" + 
       RemoteCalculator.class.getName());
   
   

   Los nombres JNDI de los beans de sesión se definen usando una sintaxis especial.

4. Invocación de métodos

   Ahora que tiene un objeto bean proxy puede invocar cualquiera de los métodos que se encuentane en la interfaz empresarial remota.

   int a = 204;
   int b = 340;
   System.out.println("Adding " + a + " and " + b + " via the remote stateless calculator deployed on the server");
   int sum = statelessRemoteCalculator.add(a, b);
   System.out.println("Remote calculator returned sum = " + sum);
   

   El bean proxy pasa la petición de la invocación del método al bean de sesión en el servidor, en donde se ejecuta. El resultado se retorna al bean proxy, el cual luego lo retorna al que realiza la llamada. La comunicación entre el bean proxy y el bean de sesión remoto es transparente para el que realiza la llamada.

Procedimiento 3.27. Ejecute EJB 2.x en JBoss EAP 6

1. Modifique el código para utilizar las nuevas reglas del espacio de nombres JNDI

   Así como con EJB 3.0, tiene que utilizar el prefijo completo JNDI con EJB 2.x. Para mayor información sobre las nuevas reglas del espacio de nombre JNDI y ejemplos del código consulte Sección 3.1.8.1, “Actualización de los nombres de espacios de nombres JNDI de la aplicación”.
   Puede encontrar los ejemplos sobre cómo actualizar los espacios de nombres JNDI de lanzamientos anteriores aquí: Sección 3.1.8.5, “Ejemplos de espacios de nombres JNDI en lanzamientos anteriores y la manera en que se especifican en JBoss EAP 6”.

2. Modifique el descriptor de archivos jboss-web.xml

   Modifique el <jndi-name> para cada <ejb-ref> para utilizar el nuevo formato de búsqueda completamente calificado JNDI.

3. Reemplace el archivo descriptor de implementación jboss.xml

   El descriptor de implementación jboss-ejb3.xml reemplaza el descriptor de implementación jboss.xml para sobreescribir y agregar a las funcionalidades proporcionadas por el descriptor de implementaciónejb-jar.xml de la edición empresarial Java (EE). El nuevo archivo es incompatible con jboss.xml y el jboss.xml ahora se ignora en las implementaciones.

4. Inicie el servidor con los perfiles completos

   EJB 2.x requiere el perfil completo de Java Enterprise Edition 6. Para iniciar JBoss EAP 6 con el perfil completo, pase el argumento -c standalone-full.xml en la línea de comandos cuando inicie el servidor.

5. Ya no se soporta el uso de clústers

   Ya no se soporta el uso de clústers de beans de entidad EJB 2.x en JBoss EAP 6.

Procedimiento 3.28. Migración de archivadores Seam 2.2

1. Actualización de la configuración de la fuente de datos

   Algunos ejemplos de Seam 2.2 usan la fuente de datos JDBC predeterminada llamada java:/ExampleDS. Esta fuente de datos predeterminada cambió en JBoss EAP 6 a java:jboss/datasources/ExampleDS. Si su aplicación usa la base de datos del ejemplo puede hacer una de las siguientes cosas:

   • Si quiere utilizar la base de datos del ejemplo que se envía junto con JBoss EAP 6, modifique el archivo META-INF/persistence.xml para reemplazar el elemento jta-data-source existente con el nombre JNDI de la fuente de datos de la base de datos:

     <!-- <jta-data-source>java:/ExampleDS</jta-data-source> -->
     <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
     

   • Si prefiere mantener su base de datos existente, puede agregar la definición de la fuente de datos al archivo EAP_HOME/standalone/configuration/standalone.xml.

     Importante

     Tiene que detener el servidor antes de modificar el archivo de configuración del servidor para que su cambio persista al reiniciar el servidor.
     La siguiente definición es una copia de la fuente de datos HSQL predeterminada definida en JBoss EAP 6:

     <datasource name="ExampleDS" jndi-name="java:/ExampleDS" enabled="true" jta="true" use-java-context="true" use-ccm="true">
        <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
        <driver>h2</driver>
        <security>
           <user-name>sa</user-name>
           <password>sa</password>
        </security>
     </datasource>
     

   • También puede agregar la definición de la fuente de datos usando la interfaz de la línea de comandos del CLI de administración. El siguiente es un ejemplo de la sintaxis que tiene que utilizar para agregar una fuente de datos. La "\" al final de la línea indica la continuación del comando en la siguiente línea.

     Ejemplo 3.1. Ejemplo de la sintaxis para agregar la definición de la fuente de datos

     $ EAP_HOME/bin/jboss-cli --connect 
     [standalone@localhost:9999 /] data-source add --name=ExampleDS --jndi-name=java:/ExampleDS \ 
           --connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 --driver-name=h2 \ 
           --user-name=sa --password=sa
     

   Para mayor información sobre cómo configurar una fuente de datos consulte Sección 3.1.6.2, “Actualización de la configuración de la fuente de datos”.

2. Agregar las dependencias requeridas

   Ya que las aplicaciones Seam 2.2 usan JSF 1.2, necesita agregar las dependencias para los módulos JSF 1.2 y excluir los módulos JSF 2.0. Para lograr esto necesita crear un archivo jboss-deployment-structure.xml en el directorio META-INF/ del EAR que contiene los siguientes datos:

   <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
     <deployment>
         <dependencies>
           <module name="javax.faces.api" slot="1.2" export="true"/>
                 <module name="com.sun.jsf-impl" slot="1.2" export="true"/>
         </dependencies>
     </deployment>
     <sub-deployment name="jboss-seam-booking.war">
       <exclusions>
           <module name="javax.faces.api" slot="main"/>
                 <module name="com.sun.jsf-impl" slot="main"/>
         </exclusions>
         <dependencies>
           <module name="javax.faces.api" slot="1.2"/>
                 <module name="com.sun.jsf-impl" slot="1.2"/>
         </dependencies>
     </sub-deployment>
   </jboss-deployment-structure>
   

   Si su aplicación usa marcos de trabajo de registro de terceros es necesario agregar esas dependencias tal como se describe aquí: Sección 3.1.4.1, “Modificar las dependencias de registros”.

3. Si su aplicación usa Hibernate 3.x, primero trate de ejecutar la aplicación usando las bibliotecas Hibernate 4

   Si su aplicación no usa el contexto de persistencia administrada Seam, la búsqueda Hibernate, validación u otras funcionalidades que han cambiado con Hibernate 4, es posible que pueda ejecutar con las bibliotecas Hibernate 4. Sin embargo, si ve ClassNotFoundExceptions o ClassCastExceptions que apuntan a las clases Hibernate o ve errores similares al siguiente puede que necesite seguir las instrucciones en el siguiente paso y modificar la aplicación para utilizar bibliotecas Hibernate 3.3.

           Caused by: java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.jboss.seam.persistence.HibernateSessionProxy.getSession(Lorg/hibernate/EntityMode;)Lorg/hibernate/Session;" the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, org/jboss/seam/persistence/HibernateSessionProxy, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for interface org/hibernate/Session have different Class objects for the type org/hibernate/Session used in the signature
   

4. Copie los archivos dependientes de fuera de los marcos de trabajo u otros lugares

   Si su aplicación usa Hibernate 3.x y no puede utilizar Hibernate 4 de manera exitosa con su aplicación, necesitará copiar las JARs Hibernate 3.x en el directorio /lib y excluir el módulo Hibernate en la sección de implementaciones del META-INF/jboss-deployment-structure.xml así:

   <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
    <deployment>
      <exclusions>
        <module name="org.hibernate"/>
      </exclusions>
    <deployment>
   </jboss-deployment-structure>
   

   Tiene que tomar pasos adicionales cuando agrupa Hibernate 3.x con su aplicación. Para mayor información, consulte Sección 3.2.2.2, “Configuración de cambios para las aplicaciones que usan Hibernate y JPA”.

5. Depurar y resolver errores JNDI Seam 2.2

   Cuando migra una aplicación Seam 2.2 puede que vea errores javax.naming.NameNotFoundException en el registro como el siguiente:

   javax.naming.NameNotFoundException: Name 'jboss-seam-booking' not found in context ''

   Si no quiere modificar las búsquedas JNDI en el código, puede modificar el archivo components.xml de la aplicación de esta manera:

   1. Reemplazar el elemento core-init existente

      Primero necesita reemplazar el elemento core-init existente así:

      <!-- <core:init jndi-pattern="jboss-seam-booking/#{ejbName}/local" debug="true" distributable="false"/>   -->
      <core:init debug="true" distributable="false"/>
      
      

   2. Busque los mensajes INFO de enlace JNDI en el registro del servidor

      Luego, busque los mensajes INFO de enlace JNDI que se imprimen en el registro del servidor cuando se implementa la aplicación. Los mensajes de enlace JNDI se deben ver de manera similar a este:

      INFO org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor (MSC service thread 1-1) JNDI bindings for session bean
      named AuthenticatorAction in deployment unit subdeployment "jboss-seam-booking.jar" of deployment "jboss-seam-booking.ear" are as follows:
          java:global/jboss-seam-booking/jboss-seam-booking.jar/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator
          java:app/jboss-seam-booking.jar/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator
          java:module/AuthenticatorAction!org.jboss.seam.example.booking.Authenticator
          java:global/jboss-seam-booking/jboss-seam-booking.jar/AuthenticatorAction
          java:app/jboss-seam-booking.jar/AuthenticatorAction
          java:module/AuthenticatorAction
      

   3. Agregar elementos del componente

      Para cada mensaje INFO de enlace JNDI en el registro, agregue un elemento component que coincida en el archivo components.xml:

      <component class="org.jboss.seam.example.booking.AuthenticatorAction" jndi-name="java:app/jboss-seam-booking.jar/AuthenticatorAction" />
      

   Para mayor información sobre cómo depurar y resolver problemas de migración consulte Sección 4.2.1, “Depurar y resolver problemas de migración”.
   Para ver una lista de problemas de migración conocidos con los archivadores Seam 2, consulte Sección 3.2.13.2, “Problemas de migración del archivador Seam 2.2 ”.