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 Dependencias de módulos implícitos en el capítulo titulado Carga de clases y módulos 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 de 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 Sinopsis de carga de clases y módulos en el capítulo titulado Carga de clases y módulos en la Guía de desarrollo para JBoss EAP 6 en https://access.redhat.com/site/documentation/JBoss_Enterprise_Application_Platform/.

Procedimiento 3.2. Cambiar la ubicación de las propiedades ResourceBundle

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>
           <!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
           <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. Si su implementación incluye implementaciones dependientes hijas también debe excluir el módulo para cada subimplementación.
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. Si prefiere poner el archivo en el directorio lib/ de su WAR, debe especificar la ruta <resource-root> en el archivo jboss-deployment-structure.xml.

   <jboss-deployment-structure>
       <deployment>
           <!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
           <exclusions>
               <module name="org.apache.log4j" />
           </exclusions>
           <resources>
               <resource-root path="lib" />
           </resources>
       </deployment>
   </jboss-deployment-structure>
   

4. Inicie el servidor JBoss EAP 6 con el siguiente argumento de tiempo de ejecución para prevenir que se presente una ClassCastException en la consola cuando implementa la aplicación:

   -Dorg.jboss.as.logging.per-deployment=false

5. Implemente su aplicación.

Procedimiento 3.6. Configuración de las dependencias de registro para JBoss EAP 6.3 o posteriores

1. Inicie el servidor JBoss EAP 6 con el siguiente argumento de tiempo de ejecución para prevenir que se presente una ClassCastException en la consola cuando implementa la aplicación:

   -Dorg.jboss.as.logging.per-deployment=false

2. Abra una terminal 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
     

3. Modifique el atributo add-logging-api-dependencies en el subsistema de registro.
   Este atributo controla si el contenedor debe agregar dependencias implícitas API de registro a sus implementaciones.

   • Si se configura como true, el cual es el valor predeterminado entonces se agregan todas las dependencias API de registro implícitas.
   • Si se configura como false entonces las dependencias no se agregan a sus implementaciones.
   Para excluir las dependencias del marco de trabajo de registro de terceros debe establecer este atributo como false utilizando el siguiente comando:

   /subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)

   Este comando agrega el elemento <add-logging-api-dependencies> al subsistema logging del archivo de configuración standalone.xml.

   <subsystem xmlns="urn:jboss:domain:logging:1.4">
       <add-logging-api-dependencies value="false"/>
       ....
   </subsystem>
   

4. Implemente su aplicación.

Procedimiento 3.7. 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.8. 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 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/.

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.9. Instalación y configuración del controlador JDBC

1. Instale el controlador JDBC.

   1. Instale el 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/. Para un dominio administrado tiene que utilizar la consola de administración o el CLI de administración para implementar la JAR en los grupos de servidores.
      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 entonces debe utilizar la consola de administración o el CLI de administración para implementar el archivo.
      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/

      • Instalación del 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. Configure la fuente de datos.

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

3. Actualización de las referencias JNDI en el código de la aplicación.

   Debe reemplazar los nombres de las búsquedas JNDI que estén desactualizados en el código fuente de la aplicación para utilizar los nuevos nombres de la fuente de datos estándar JNDI que haya definido. Para obtener mayor información, consulte: Sección 3.1.8.4, “Modifique la aplicación a seguir las nuevas reglas de los espacios de nombre JNDI”.
   También debe reemplazar cualquier anotación @Resource existente que acceda la fuente de datos para utilizar el nuevo nombre JNDI. Por ejemplo:

   @Resource(name = "java:/YourDatasourceName").
   

Procedimiento 3.10. 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.11. Desactivación de chequeos adicionales de autorización

• Puede desactivar los chequeos adicionales de autorización y seguir utilizando las implementaciones PicketLink existentes utilizando uno de los siguientes métodos.

  • Configuración de una propiedad a nivel del sistema

    Puede desactivar chequeos adicionales de autorización a nivel del servidor configurando el valor de la propiedad del sistema org.jboss.ws.cxf.disableHandlerAuthChecks como true. Este método afecta cualquier implementación realizada en el servidor de aplicaciones.
    Para obtener mayor información sobre cómo configurar una propiedad del sistema consulte la sección titulada Configuración de propiedades del sistema utilizando el CLI de administración en la Guía de configuración y administración para JBoss EAP.

  • Creación de una propiedad en el archivo descriptor de servicios web de la implementación

    Puede desactivar chequeos adicionales de autorización a nivel de la implementación configurando el valor de la propiedad org.jboss.ws.cxf.disableHandlerAuthChecks como true en el archivo jboss-webservices.xml. Este método tiene impacto solo en la implementación especifica.
    1. Cree un archivo jboss-webservices.xml en el directorio META-INF/ de la implementación en la que quiere desactivar los chequeos adicionales de autorización.
    2. Agregue el siguiente contenido:

       <?xml version="1.1" encoding="UTF-8"?>
       <webservices xmlns="http://www.jboss.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         version="1.2" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee">
         <property>
           <name>org.jboss.ws.cxf.disableHandlerAuthChecks</name>
           <value>true</value>
         </property>
       </webservices>

Procedimiento 3.12. 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.13. 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.14. 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.

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.

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 tal como se observa en la siguiente tabla.

   Tabla 3.5. Tabla de mapeo de espacios de nombres DTD

   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. Modificación de las variables de 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.15. 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.16. 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.17. 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.18. Creación de un puente JMS

1. Configuración del puente en el servidor JBoss EAP 5.x fuente

   Para evitar conflictos en las clases entre lanzamientos tiene que seguir estos pasos para configurar el puente JMS en JBoss EAP 5.x. Los nombres del directorio SAR y el puente son arbitrarios y se pueden cambiar si así lo prefiere.
   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 en el diretcorio EAP5_HOME/server/PROFILE_NAME/deploy/myBridge.sar/META-INF/. Debe contener información similar al siguiente ejemplo:

      <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 elemento 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á asegurado 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.

2. Configuración del puente en el servidor JBoss EAP 6 destino

   En JBoss EAP 6.1 y posteriores, el puente JMS se puede utilizar para transferir mensajes de cualquier servidor que cumpla con los requerimientos de JMS 1.1. Ya que los recursos JMS destino y fuente se buscan usando JNDI, las clases de búsqueda JNDI del proveedor de mensajería fuente o agente de mensajería se debe agrupar en un módulo JBoss. Los siguientes pasos utilizan el agente de mensajería ficticio 'MyCustomMQ' como ejemplo.
   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 proporcionan 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.19. 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.20. 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.5, “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”.

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

   $ EAP5_HOME/bin/run.sh -c all -b 192.168.0.2

   JBoss EAP 6 enlaza sockets a las direcciones IP e interfaces que se encuentran en los elementos <interfaces> en los archivos standalone.xml, domain.xml y host.xml. Las configuraciones estándar que se envían junto con JBoss EAP incluyen dos configuraciones de interfaz:

   <interfaces>
       <interface name="management">
           <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
       </interface>
       <interface name="public">
          <inet-address value="${jboss.bind.address:127.0.0.1}"/>
       </interface>
   </interfaces>

   Estas configuraciones de interfaz usan los valores de las propiedades del sistema jboss.bind.address.management y jboss.bind.address. Si estas propiedades del sistema no se establecen entonces se utiliza el valor predeterminado 127.0.0.1 para cada valor.
   También puede especificar la dirección de enlace como un argumento de la línea de comandos cuando inicia el servidor o puede definirla explícitamente dentro del archivo de configuración del servidor JBoss EAP 6.
   • Especifique el argumento de enlace en la línea de comandos cuando incia el servidor autónomo JBoss EAP.
     El siguiente es un ejemplo de cómo especificar la dirección de enlace en la línea de comandos para un servidor autónomo:

     EAP_HOME/bin/standalone.sh -Djboss.bind.address=127.0.0.1

     Nota

     También puede utilizar el argumento -b, el cual es un atajo para -Djboss.bind.address=127.0.0.1:

     EAP_HOME/bin/standalone.sh -b=127.0.0.1

     El formato de la sintaxis de JBoss EAP 5 todavía se soporta:

     EAP_HOME/bin/standalone.sh -b 127.0.0.1

     Note que el argumento -b solo cambia la interfaz public. No afecta la interfaz management.
   • Especifique la dirección de enlace en el archivo de configuración del servidor.
     Para los servidores ejecutando en un dominio administrado, especifique las direcciones de enlace en el archivo domain/configuration/host.xml. Para los servidores autónomos especifique las direcciones de enlace en el archivo standalone-ha.xml.
     En el siguiente ejemplo, la interfaz public se especifica como la interfaz predeterminada para todos los sockets dentro del grupo de enlace de sockets ha-sockets.

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

     Nota

     Si especifica la dirección de enlace como un valor definido en lugar de una propiedad del sistema en el archivo de configuración entonces no puede sobreescribirlo con un argumento de la línea de comandos.

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

   $ EAP5_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 utilizando 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.

   $ EAP5_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 JBoss Cache Buddy Replication para eliminar la replicación de datos en todas las instancias en un clúster.
   En JBoss EAP 6, la replicación de compañeros fue reemplazada por el caché distribuído de Infinispan también conocido como el 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 modifican el elemento dist <distributed-cache> en la configuración web <cache-container> en el subsistema infinispan del archivo standalone-ha.xml así:

      <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 Clústers en aplicaciones web en la Guía de desarrollo 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.21. Implementación de un servicio Singleton HA

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

   El siguiente es un ejemplo simple de un Service envuelto con el decorador SingletonService para ser implementado como un servicio singleton. Puede encontrar un ejemplo completo en la guía de inicio rápido de cluster-ha-singleton que se envía junto con Red Hat JBoss Enterprise Application Platform 6. Esta guía de inicio rápido contiene todas las instrucciones para construir e implementar la aplicación.

   1. Crear un servicio.

      El siguiente listado es un ejemplo de un servicio:

      package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
      
      import java.util.Date;
      import java.util.concurrent.atomic.AtomicBoolean;
      
      import javax.naming.InitialContext;
      import javax.naming.NamingException;
      
      import org.jboss.logging.Logger;
      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;
      
      
      /**
       * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
       */
      public class HATimerService implements Service<String> {
          private static final Logger LOGGER = Logger.getLogger(HATimerService.class);
          public static final ServiceName SINGLETON_SERVICE_NAME = ServiceName.JBOSS.append("quickstart", "ha", "singleton", "timer");
      
          /**
           * A flag whether the service is started.
           */
          private final AtomicBoolean started = new AtomicBoolean(false);
      
          /**
           * @return the name of the server node
           */
          public String getValue() throws IllegalStateException, IllegalArgumentException {
              LOGGER.infof("%s is %s at %s", HATimerService.class.getSimpleName(), (started.get() ? "started" : "not started"), System.getProperty("jboss.node.name"));
              return "";
          }
      
          public void start(StartContext arg0) throws StartException {
              if (!started.compareAndSet(false, true)) {
                  throw new StartException("The service is still started!");
              }
              LOGGER.info("Start HASingleton timer service '" + this.getClass().getName() + "'");
      
              final String node = System.getProperty("jboss.node.name");
              try {
                  InitialContext ic = new InitialContext();
                  ((Scheduler) ic.lookup("global/jboss-cluster-ha-singleton-service/SchedulerBean!org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.Scheduler")).initialize("HASingleton timer @" + node + " " + new Date());
              } catch (NamingException e) {
                  throw new StartException("Could not initialize timer", e);
              }
          }
      
          public void stop(StopContext arg0) {
              if (!started.compareAndSet(true, false)) {
                  LOGGER.warn("The service '" + this.getClass().getName() + "' is not active!");
              } else {
                  LOGGER.info("Stop HASingleton timer service '" + this.getClass().getName() + "'");
                  try {
                      InitialContext ic = new InitialContext();
                      ((Scheduler) ic.lookup("global/jboss-cluster-ha-singleton-service/SchedulerBean!org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.Scheduler")).stop();
                  } catch (NamingException e) {
                      LOGGER.error("Could not stop timer", e);
                  }
              }
          }
      }
      

   2. Cree un activador que instala el Service como un singleton en clúster.

      El siguiente listado es un ejemplo de un activador Service que instala el HATimerService como un servicio singleton en clúster:

      package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
      
      import org.jboss.as.clustering.singleton.SingletonService;
      import org.jboss.logging.Logger;
      import org.jboss.msc.service.DelegatingServiceContainer;
      import org.jboss.msc.service.ServiceActivator;
      import org.jboss.msc.service.ServiceActivatorContext;
      import org.jboss.msc.service.ServiceController;
      
      
      /**
       * Service activator that installs the HATimerService as a clustered singleton service
       * during deployment.
       *
       * @author Paul Ferraro
       */
      public class HATimerServiceActivator implements ServiceActivator {
          private final Logger log = Logger.getLogger(this.getClass());
      
          @Override
          public void activate(ServiceActivatorContext context) {
              log.info("HATimerService will be installed!");
      
              HATimerService service = new HATimerService();
              SingletonService<String> singleton = new SingletonService<String>(service, HATimerService.SINGLETON_SERVICE_NAME);
              /*
               * To pass a chain of election policies to the singleton, for example, 
               * to tell JGroups to prefer running the singleton on a node with a
               * particular name, uncomment the following line:
               */
              // singleton.setElectionPolicy(new PreferredSingletonElectionPolicy(new SimpleSingletonElectionPolicy(), new NamePreference("node2/cluster")));
      
              singleton.build(new DelegatingServiceContainer(context.getServiceTarget(), context.getServiceRegistry()))
                      .setInitialMode(ServiceController.Mode.ACTIVE)
                      .install()
              ;
          }
      }
      

      Nota

      El código ejemplo anterior usa una clase, org.jboss.as.clustering.singleton.SingletonService, que es parte de la API privada JBoss EAP. Una API pública se hará disponible en el lanzamiento EAP 7 y la clase privada ya no se utilizará, pero estas clases se mantendrán y estarán disponibles durante el ciclo de lanzamiento de EAP 6.x.

   3. Creación de un archivo ServiceActivator

      Cree un archivo llamado org.jboss.msc.service.ServiceActivator en el directorio resources/META-INF/services/ de la aplicación. Agregue una línea que contenga el nombre completamente calificado de la clase ServiceActivator creada en el paso anterior.

      org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator 

   4. Cree un bean Singleton que implementa un temporizador a utilizarse como temporizador singleton a nivel de clúster.

      Este bean Singleton no debe tener una interfaz remota y no debe hacer referencia a su interfaz local desde otro EJB en ninguna aplicación. Esto evita una búsqueda por parte de un cliente u otro componente y se asegura de que el SingletonService tenga control total del Singleton.

      1. Creación de la interfaz del programador

         package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
         
         /**
          * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
          */
         public interface Scheduler {
         
             void initialize(String info);
         
             void stop();
         
         }
         

      2. Crear el bean Singleton que implementa el temporizador singleton a nivel de clúster.

         package org.jboss.as.quickstarts.cluster.hasingleton.service.ejb;
         
         import javax.annotation.Resource;
         import javax.ejb.ScheduleExpression;
         import javax.ejb.Singleton;
         import javax.ejb.Timeout;
         import javax.ejb.Timer;
         import javax.ejb.TimerConfig;
         import javax.ejb.TimerService;
         
         import org.jboss.logging.Logger;
         
         
         /**
          * A simple example to demonstrate a implementation of a cluster-wide singleton timer.
          *
          * @author <a href="mailto:wfink@redhat.com">Wolf-Dieter Fink</a>
          */
         @Singleton
         public class SchedulerBean implements Scheduler {
             private static Logger LOGGER = Logger.getLogger(SchedulerBean.class);
             @Resource
             private TimerService timerService;
         
             @Timeout
             public void scheduler(Timer timer) {
                 LOGGER.info("HASingletonTimer: Info=" + timer.getInfo());
             }
         
             @Override
             public void initialize(String info) {
                 ScheduleExpression sexpr = new ScheduleExpression();
                 // set schedule to every 10 seconds for demonstration
                 sexpr.hour("*").minute("*").second("0/10");
                 // persistent must be false because the timer is started by the HASingleton service
                 timerService.createCalendarTimer(sexpr, new TimerConfig(info, false));
             }
         
             @Override
             public void stop() {
                 LOGGER.info("Stop all existing HASingleton timers");
                 for (Timer timer : timerService.getTimers()) {
                     LOGGER.trace("Stop HASingleton timer: " + timer.getInfo());
                     timer.cancel();
                 }
             }
         }
         

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

   Para habilitar el uso de clústers para servidores autónomos, inicie cada servidor con el perfil HA utilizando un nodo único y compensación de puertos para cada instancia.
   • Para Linux use la siguiente sintaxis de comandos para iniciar los servidores:

     EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME -Djboss.socket.binding.port-offset=PORT_OFFSET

     Ejemplo 3.1. Inicio de múltiples servidores autónomos en Linux

     $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=node1
     $ EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100

   • Para Microsoft Windows use la siguiente sintaxis de comandos para iniciar los servidores:

     EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=UNIQUE_NODE_NAME -Djboss.socket.binding.port-offset=PORT_OFFSET

     Ejemplo 3.2. Inicio de múltiples servidores autónomos en Microsoft Windows

     C:> EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=node1
     C:> EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=100

   Nota

   Si prefiere no utilizar argumentos de la línea de comandos entonces puede configurar el archivo standalone-ha.xml para cada instancia de servidor para enlazar en una interfaz por separado.

3. Implemente la aplicación en los servidores

   El siguiente comando Maven implementa la aplicación en un servidor autónomo ejecutando en los puertos predeterminados.

   mvn clean install jboss-as:deploy

   Para implementar en servidores adicionales, pase el nombre del servidor. Si es un host diferente, pase el nombre del host y el número del puerto en la línea de comandos:

   mvn clean package jboss-as:deploy -Djboss-as.hostname=localhost -Djboss-as.port=10099

   Consulte el inicio rápido cluster-ha-singleton que se envía junto con JBoss EAP 6 para ver los detalles de la implementación y configuración de Maven.

Procedimiento 3.22. 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-ejb-remote-server-side</artifactId>
      <type>ejb-client</type>
      <version>${project.version}</version>
   </dependency>

Procedimiento 3.23. 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-ejb-remote-server-side//CalculatorBean!" + 
       RemoteCalculator.class.getName());
   

   Los nombres JNDI de beans de sesión se definen utilizando una sintaxis especial. Para mayor información consulte Sección 3.2.10.3, “Referencia de nombrado JNDI EJB” .

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.25. 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.3. 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 ”.