Guía para la migración de IBM Rational Application Developer para Windows y Linux, Versión 6.0


Contenido

Capítulo 1. Migrar de WebSphere Studio V5.1, V5.1.1 o V5.1.2

  • Compatibilidad con WebSphere Studio V5.1.x
  • Inhabilitar la compatibilidad con WebSphere Studio V5.1.x
  • Actualizar recursos de tiempo de ejecución de Faces en un proyecto Web
  • Actualizar recursos de tiempo de ejecución de cliente Faces en un proyecto Web
  • Migrar proyectos Web de Struts
  • Cambios que presenta el depurador en la V6.0
  • Migración de WDO a SDO
  • Palabras reservadas del EGL en V6.0
  • Capítulo 2. Actualizar recursos de tiempo de ejecución de Faces para proyectos Web de Rational Application Developer V6.0

    Capítulo 3. Actualizar recursos de tiempo de ejecución de Faces para proyectos de portlet de Rational Application Developer V6.0

    Capítulo 4. Migrar proyectos J2EE

  • Migrar servicios Web seguros
  • Migración del nivel de especificación J2EE 1.3 al nivel de especificación J2EE 1.4
  • Proyectos Enterprise JavaBean (de EJB 2.0 a EJB 2.1)
  • Proyectos Web (del nivel Servlet 2.3 al nivel Servlet 2.4)
  • Proyectos de conector (de JCA 1.0 a JCA 1.5)
  • Servicios Web (de J2EE 1.3 a J2EE 1.4)
  • Migración del nivel de especificación J2EE 1.2 al nivel de especificación J2EE 1.4
  • Migrar proyectos JavaBeans (de EJB 1.1 a EJB 2.1)
  • Proyectos Web (del nivel Servlet 2.2 al nivel Servlet 2.4)
  • Cambios que presenta el asistente de migración J2EE en Rational Application Developer V6.0
  • Capítulo 5. Migrar a Portal Tools de Rational Application Developer V6.0

  • Migrar los portlets de WebSphere Portal V4.2 a la V5.x
  • Actualizar recursos de tiempo de ejecución de Faces en un proyecto de portlet
  • Capítulo 6. Cambios realizados en los entornos de prueba de WebSphere



    Capítulo 1. Migrar de WebSphere Studio V5.1, V5.1.1 o V5.1.2

    En esta documentación se facilitan instrucciones para migrar de WebSphere Studio Application Developer V5.1.x a Rational Application Developer V6.0.

    Podrá encontrar información adicional en los temas:

    En la ayuda en línea encontrará información sobre cómo utilizar Rational Application Developer.

    Consulte el sitio www.ibm.com/developerworks/rational para obtener documentación actualizada.

    Para obtener información sobre cómo migrar de las versiones anteriores de WebSphere Studio a la V5.x o sobre cómo migrar de VisualAge para Java a WebSphere Studio, vaya a www.ibm.com/software/awdtools/studioappdev/support/ y busque "migration guide" (guía de migración).

    Para migrar de WebSphere Studio V5.1.x:

    1. Antes de proceder a la instalación, lea el tema sobre la compatibilidad con Eclipse V2.x y WebSphere Studio V5.1.x. Tenga en cuenta que la retrocompatibilidad no está soportada para los proyectos de aplicaciones portlet que se hayan migrado de Portal Toolkit V5.0.2.2 con WebSphere Studio V5.1.2.
    2. Haga copia de seguridad del área de trabajo de WebSphere Studio V5.1.x.
    3. Instale el producto Rational Application Developer. Consulte la guía de instalación (archivo install.html) que está disponible en el directorio raíz del primer CD del producto.
    4. Recomendación: por omisión, la primera vez que inicia Rational Application Developer, se le pedirá que confirme que desea utilizar un área de trabajo llamada rationalsdp6.0\workspace. Es decir, el diálogo de lanzamiento del área de trabajo señala hacia un directorio que no es el área de trabajo de WebSphere Studio. Para explorar el nuevo entorno antes de migrar la antigua área de trabajo, acepte el valor predeterminado o bien especifique otro nombre de directorio nuevo cuando inicie Rational Application Developer. Le interesará hacerlo para, por ejemplo, poder crear uno o dos proyectos de prueba, enterarse de las novedades (Ayuda -> Bienvenido), seguir las instrucciones de algunas guías de aprendizaje (Ayuda -> Galería de guías de aprendizaje) o bien experimentar con algunos de los nuevos ejemplos (Ayuda -> Galería de ejemplos).
    5. Migrar los proyectos a V6.0. Los proyectos creados en WebSphere Studio V5.1.x pueden migrarse automáticamente a V6.0 de la forma siguiente:
      1. Migrar un área de trabajo: Cuando ya esté listo para migrar definitivamente el área de trabajo de la V5.1.x, inicie Rational Application Developer con la antigua área de trabajo. Verá un indicador de progreso que confirma que los proyectos se están migrando automáticamente.

        Notas: Durante la migración del área de trabajo, se abrirá un diálogo Problemas con el mensaje No se ha podido restaurar el diseño del entorno de trabajo. Razón: se produjeron problemas al restaurar el entorno de trabajo. Los mensajes de error no afectan a la migración satisfactoria del área de trabajo. Tome nota de la perspectiva que no se ha podido restaurar; para ello, pulse el botón Detalles del diálogo de error, y después pulse Aceptar para cerrar el diálogo.

        Para restaurar la perspectiva:

        1. Cierre la perspectiva, seleccionando Ventana -> Cerrar perspectiva.
        2. Vuelva a abrir la perspectiva, seleccionando Ventana -> Abrir perspectiva.
        Nota:
        En el caso de los proyectos del lenguaje de generación para empresas (EGL) que utilizaron la perspectiva Web EGL en WebSphere Studio V5.1.2: esta perspectiva se ha eliminado en Rational Application Developer V6.0. All EGL projects are safely migrated without this perspective in Rational Application Developer V6.0. Si ha utilizado la perspectiva Web EGL, haga lo siguiente:
        1. Cierre la perspectiva Web EGL.
        2. Habilite las prestaciones EGL en las preferencias (Ventana -> Preferencias). En la ayuda en línea hallará los detalles sobre cómo habilitar las prestaciones EGL.
        3. Seleccione Ventana -> Abrir perspectiva y elija la perspectiva Web.
      2. Migrar los proyectos cargados en un sistema SCM (gestión de código fuente): los proyectos de WebSphere Studio 5.1.x que existen en un sistema SCM se migran automáticamente a V6.0 cuando se cargan en Rational Application Developer.
      3. Migrar proyectos importados utilizando Intercambio de proyectos: los proyectos exportados de WebSphere Studio V5.1.2 o V5.1.1 e importados en Rational Application Developer V6.0 utilizando la característica Intercambio de proyectos se migran automáticamente a V6.0. La característica Intercambio de proyectos estaba disponible en WebSphere Studio V5.1.2 y era un conector opcional para V5.1.1.

      Notas:

      Importante:

    6. El controlador JDBC de DB2 Net no se puede utilizar en Rational Application Developer V6.0. Si ha creado conexiones JDBC mediante el controlador JDBC de DB2 Net, no podrá volver a conectar en Rational Application Developer V6.0. Será preciso que cambie la conexión para que utilice uno de los controladores JDBC permitidos en el producto. En la ayuda en línea hallará más información sobre los controladores JDBC que se pueden utilizar en la V6.0.
    7. Si tiene contenido de un archivo Web o XML que haya migrado de WebSphere Studio Application Developer V5.1.x y que utilizaba el juego de caracteres Shift_JIS e incluía caracteres seleccionados por el proveedor, debe especificar en su lugar el juego de caracteres Windows-31J.
    8. Si ha instalado conectores de algún proveedor con el producto WebSphere Studio Application Developer V5.1.x, deberá obtener los correspondientes conectores de la V6.0 y volver a instalarlos.
    9. Si ha instalado entornos de prueba unitaria de WebSphere V5.x que sean de un nivel anterior al instalar Rational Application Developer y si además utiliza el servicio de mensajería incorporada, debe actualizarlo, instalando la versión que viene con Rational Application Developer. En la guía de instalación encontrará los detalles para instalar el servicio de mensajería incorporada.
    10. Si utiliza características que requieran Agent Controller, actualícelo, instalando la versión que viene con Rational Application Developer. Encontrará los detalles en la guía de instalación.
    11. Para migrar de VisualAge Generator, consulte la guía de migración de VisualAge Generator al lenguaje de generación para empresas (EGL), que está disponible en formato PDF en la sección que explica cómo "instalar y migrar" de la ayuda en línea, en el tema que indica cómo "acceder a la guía de migración de VisualAge Generator a EGL". En http://www.ibm.com/developerworks/rational/library/egldoc.html encontrará la copia más reciente.

    Compatibilidad con WebSphere Studio V5.1.x

    La primera vez que abre un área de trabajo de WebSphere Studio V5.1.x en Rational Application Developer, se realiza una migración automática del área. Una vez que haya migrado un área de trabajo, ya no podrá abrirla en WebSphere Studio Application Developer. Sin embargo, los proyectos del área de trabajo de V6.0 todavía se pueden compartir con WebSphere Studio V5.1.x, ya sea utilizando un sistema de gestión de código fuente (SCM) (como puede ser Rational ClearCase), importando y exportando el proyecto utilizando el Intercambio de proyectos o bien importando los archivados y exportando los proyectos. Importante: las aplicaciones portlet de Portal Toolkit V5.0.2.2 que se migren a Portal Tools de Rational Application Developer V6.0 no serán retrocompatibles.

    Nota:
    Los siguientes puntos no atañen a las aplicaciones portlet.

    Los proyectos existentes en V5.1.x que se carguen en V6.0 a partir de un sistema SCM o de otro desarrollador utilizando el Intercambio de proyectos serán compatibles y se podrán compartir con V5.1.x, siempre y cuando no se lleve a cabo ninguna de estas acciones:

    Cuando se abre un proyecto de V5.1.x en el área de trabajo de Rational Application Developer V6.0, se crea automáticamente un archivo .compatibility en el directorio del proyecto. El producto Rational Application Developer utiliza el archivo .compatibility para hacer un seguimiento de las indicaciones de la hora de los recursos del proyecto al migrarlos. No debe editarlo ni suprimirlo.

    Encontrará información sobre cómo inhabilitar la compatibilidad con WebSphere Studio Application Developer V5.1.x en: Inhabilitar la compatibilidad con WebSphere Studio V5.1.x.

    Consideraciones sobre Eclipse

    Esta versión de Rational Application Developer está basada en Eclipse V3.0. Si desarrolla conectores propios, debe informarse sobre los cambios realizados en la plataforma antes de migrar.

    Los detalles están en el archivo readme del subdirectorio eclipse\readme de la ubicación de instalación de Rational Application Developer V6.0. Los apartados del archivo readme que resultan interesantes de cara a la migración son:

    Compatibilidad de los proyectos J2EE

    La compatibilidad de los proyectos creados en WebSphere Studio V5.1.x con Rational Application Developer V6.0 se habilita por medio de los metadatos que se añaden automáticamente a los archivos .project en el momento de migrar el área de trabajo de V5.1.x. De igual modo, si crea un módulo o una aplicación J2EE 1.2 o J2EE 1.3 en Rational Application Developer V6.0, se añaden automáticamente metadatos de construcción al archivo .project para proporcionar compatibilidad con V5.1.x. No debe editar ni suprimir esta información directamente.

    Nota:
    Los metadatos de compatibilidad harán que se visualicen o anoten mensajes que advierten de que faltan constructores cuando un nuevo módulo o aplicación J2EE 1.2 y J2EE 1.3 creado en V6.0 se utilice en WebSphere Studio Application Developer V5.1.x, donde no están disponibles los constructores de V6.0. Estos mensajes son normales; no hace falta hacerles caso.

    Mientras estén presentes los metadatos de compatibilidad, recibirá mensajes que advierten de que faltan constructores cuando los proyectos de Rational Application Developer V6.0 se cargan de nuevo en WebSphere Studio V5.1.x. A continuación se proporciona un mensaje de ejemplo que advierte de la falta de un constructor:

    !ENTRY org.eclipse.core.resources 2 1 Sep 06, 2004 19:55:20.592
    !MESSAGE Omitiendo constructor com.ibm.wtp.j2ee.LibCopyBuilder para proyecto Test60EARWeb. 
    El constructor no se encuentra en la instalación o pertenece a una naturaleza de proyecto que falta o está inhabilitada.
    

    Estos mensajes son normales; no hace falta hacerles caso. Cuando tenga la seguridad de que ya no necesita trabajar más con un proyecto dado en WebSphere Studio V5.1.x, puede evitar que aparezcan estos mensajes inhabilitando la retrocompatibilidad en ese proyecto.

    Importante: los nuevos proyectos de la especificación J2EE 1.2 o J2EE 1.3 creados en V6.0 son retrocompatibles con WebSphere Studio V5.1.x, pero una vez que los proyectos se hayan cargado en WebSphere Studio, hará falta realizar algunos pasos manuales para poder trabajar con ellos. Son pasos necesarios porque los destinos de tiempo de ejecución en los nuevos proyectos de la especificación J2EE 1.2 o J2EE 1.3 creados en V6.0 no son directamente retrocompatibles en los servidores destino de V5.1.x. Los pasos manuales que deben realizarse cuando un proyecto nuevo de V6.0 se carga en V5.1.x son los siguientes:

    1. Abra el archivo .classpath de cada proyecto J2EE que tenga ese archivo.
    2. Suprima las siguientes entradas de vía de acceso de clases (classpathentry) del archivo .classpath y, después, guarde el archivo y ciérrelo.
    3. Asegúrese de que el soporte de direccionamiento a servidor está habilitado en la página de preferencias de J2EE. Seleccione Ventana -> Preferencias -> J2EE y confirme que hay una marca de selección en la opción Habilitar soporte de direccionamiento a servidor, en "Soporte de direccionamiento a servidor".
    4. Pulse el proyecto con el botón derecho del ratón y seleccione Propiedades -> J2EE.
    5. Seleccione el correspondiente servidor destino para el destino de tiempo de ejecución del proyecto (por ejemplo, WebSphere Application Server V5.1 utilizando el entorno de tiempo de ejecución JDK 1.4) y pulse Aceptar.
    6. El servidor destino que ha seleccionado será compatible para Rational Application Developer V6.0 y WebSphere Studio Application Developer V5.1.x. Después de haber comprometido los cambios en el sistema SCM, los proyectos J2EE serán interoperativos entre V5.1.x y V6.0 mediante un sistema SCM.
      Nota:
      Si el servidor destino se vuelve a establecer en Rational Application Developer V6.0, se perderá la compatibilidad de los proyectos J2EE y habrá que restablecerla.

    Compatibilidad de los diagramas UML

    Los diagramas UML que ya existían en WebSphere Studio Application Developer V5.1.x son compatibles con las versiones posteriores y se pueden abrir en modalidad solo de lectura en Rational Application Developer V6.0. En V6.0, el asistente de migración J2EE migra automáticamente los diagramas UML creados en los proyectos J2EE de V5.1.x durante la migración de la estructura del proyecto J2EE. Una vez migrados, los diagramas UML se pueden editar en Rational Application Developer V6.0.

    Nota:
    Los diagramas UML de un área de trabajo migrada al producto Rational Application Developer V6.0 o creada en él no se pueden abrir en WebSphere Studio Application Developer V5.1.x.

    Inhabilitar la compatibilidad con WebSphere Studio V5.1.x

    La compatibilidad con WebSphere Studio Application Developer V5.1.x se puede eliminar totalmente de un proyecto de aplicación de empresa creado en Rational Application Developer V6.0 o de un proyecto de aplicación de empresa que se haya migrado de una versión anterior de WebSphere Studio. Solo debe inhabilitar la compatibilidad con WebSphere Studio V5.1.x si está seguro de que el proyecto de aplicación de empresa ya no debe interoperar ni ser compatible con la V5.1.x.

    Para eliminar la compatibilidad con WebSphere Studio Application Developer V5.1.x:

    1. Pulse un proyecto de aplicación de empresa con el botón derecho del ratón y seleccione la opción Eliminar compatibilidad en el menú emergente.
    2. Se abrirá un diálogo para pedirle que confirme que realmente quiere eliminar la retrocompatibilidad del proyecto de aplicación de empresa, así como de todos los proyectos de módulos y de utilidades anidados en el proyecto.
    3. Pulse si desea seguir adelante con la operación de eliminar la compatibilidad.

    Cuando la operación de eliminar la compatibilidad ya se haya ejecutado, el proyecto de aplicación de empresa y todos los proyectos de módulos y utilidades anidados en él dejan de ser retrocompatibles con WebSphere Studio Application Developer V5.1.x.


    Actualizar recursos de tiempo de ejecución de Faces en un proyecto Web

    Los recursos de tiempo de ejecución de JavaServer Faces enviados con WebSphere Studio Application Developer V5.1.x se han actualizado para Rational Application Developer V6.0.1. Si desea seguir desarrollando proyectos Web creados con esta versión anterior del producto, es recomendable que actualice los recursos de tiempo de ejecución de Faces a los últimos niveles.

    En Rational Application Developer V6.0.1, las actualizaciones de recursos de tiempo de ejecución de Faces ocurren automáticamente cuando se importa un proyecto Web o se abre un área de trabajo que contiene recursos no actualizados. Después de importar un proyecto Web o abrir un área de trabajo de WebSphere Studio Application Developer V5.1.x a Rational Application Developer V6.0.1, se le solicitará actualizar los recursos de tiempo de ejecución de Faces a los últimos niveles.

    Actualizar automáticamente recursos de tiempo de ejecución

    Para actualizar automáticamente los recursos de tiempo de ejecución de Faces para un proyecto Web:

    1. Importe un proyecto Web (o un área de trabajo) con contenido de Faces de WebSphere Studio Application Developer V5.1.x. Se abre la ventana Migración de proyectos.
      Nota:
      Si la ventana Migración de proyectos no se abre, el valor de preferencia de construcción automática esté probablemente inhabilitado. En el Explorador de proyecto, pulse con el botón derecho del ratón sobre el proyecto Web y seleccione Construir -> Proyecto; el proceso de reconstrucción de un proyecto abre la ventana Migración de proyectos.
    2. Si tiene otros proyectos Web con contenido de Faces en el área de trabajo, marque Aplicar esta opción a cualesquiera otros proyectos que necesiten actualizarse y se actualizarán todos los proyectos Web.
    3. Pulse una de las opciones siguientes:
    Nota:
    Si ha creado JSP Faces que contenían componentes de cliente Faces, debe actualizar por separado los recursos de tiempo de ejecución de componentes de cliente Faces a los últimos niveles. Consulte Actualizar recursos de tiempo de ejecución de cliente Faces en un proyecto Web.

    Actualizar manualmente recursos de tiempo de ejecución

    Para actualizar manualmente los recursos de tiempo de ejecución de Faces para un proyecto Web:

    1. Importe el proyecto Web existente con el contenido Faces a un área de trabajo de Rational Application Developer V6.0.1.
    2. Cree un proyecto Web nuevo (o si está trabajando con EGL, cree un proyecto Web de EGL nuevo) llamado JSF601. Este proyecto tan solo lo utilizará como origen de los recursos de tiempo de ejecución más recientes; puede suprimirse una vez realizada la actualización.
    3. En el explorador de proyectos, pulse el proyecto JSF601 con el botón derecho del ratón y seleccione Propiedades en el menú.
    4. Pulse Características de proyecto Web y seleccione Añadir componentes de base Faces y Añadir infraestructura de cliente Faces y pulse Aceptar.
    5. Si está trabajando con EGL, cree un archivo de página JSF de la forma siguiente:
      1. Pulse el botón derecho del ratón sobre la carpeta WebContent del proyecto Web EGL nuevo.
      2. Seleccione Nuevo -> Otros -> Archivo JSP Faces.
      Los archivos eglintdebug.jar y eglintdebugsupport.jar se añaden al proyecto.
    6. Para cada proyecto Faces existente que desee actualizar, haga lo siguiente:
      1. Expanda un proyecto existente en el Explorador de proyectos para ver los archivos que hay en la carpeta WebContent/WEB-INF/lib/. En este directorio, localice cada uno de los siguientes archivos JAR y suprímalos:
        • eglintdebug.jar (solo EGL)
        • eglintdebugsupport.jar (solo EGL)
        • fda.jar (solo EGL)
        • fdaj.jar (solo EGL)
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • odc-jsf.jar
      2. Localice el archivo WebContent/WEB-INF/faces-config.xml. Añada los siguientes elementos a este archivo de configuración, si todavía no están presentes:
        	<lifecycle>
        		<phase-listener>com.ibm.faces.webapp.ValueResourcePhaseListener</phase-listener>
        	</lifecycle>
        	
        	<application>
        		<variable-resolver>com.ibm.faces.databind.SelectItemsVarResolver</variable-resolver>
        		<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
        	</application>
        
      3. Por cada uno de los archivos JAR que suprimió, copie el archivo JAR que tenga el mismo nombre en el directorio WebContent/WEB-INF/lib del proyecto JSF601 y péguelo en el proyecto original en la misma ubicación. En algunas configuraciones no hará falta que todos estos archivos JAR estén presentes en el proyecto; no copie un archivo JAR determinado si no estaba en el proyecto original.
      4. Abra el descriptor de despliegue web.xml del proyecto original y añada las siguientes líneas de código a la configuración:
        	<context-param>
        		<param-name>com.ibm.ws.jsf.JSP_UPDATE_CHECK</param-name>
        		<param-value>true</param-value>
        	</context-param>
        	<context-param>
        		<param-name>com.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP</param-name>
        		<param-value>true</param-value>
        	</context-param>
        
      5. Si el proyecto original utiliza Objetos de datos de WebSphere (WDO) para cualquier acceso de datos, siga estos pasos adicionales:
        1. En el proyecto original, pulse Archivo -> Nuevo -> Archivo JSP Faces para crear un archivo JSP Faces temporal nuevo.
        2. Arrastre un componente de lista de registro relacional de la bandeja Datos de la paleta a la página.
        3. Seleccione cualquier conexión y origen de datos y pulse Finalizar. Los datos seleccionados no son importantes. Este proceso generará la configuración necesaria para continuar utilizando WDO en este proyecto.
        4. Suprima el archivo JSP temporal.
      6. Si está trabajando con EGL, pulse con el botón derecho del ratón sobre el nombre de cada proyecto Web EGL y pulse Generar; si no está construyendo los proyectos automáticamente, pulse Proyecto -> Construir todo.
    7. Suprima el proyecto Web JSF601.

    Actualizar recursos de tiempo de ejecución de cliente Faces en un proyecto Web

    Los recursos de tiempo de ejecución del cliente JavaServer Faces enviados con WebSphere Studio Application Developer V5.1.x se han actualizado para Rational Application Developer V6.0.1. Si desea seguir desarrollando proyectos Web creados con esta versión anterior del producto, es recomendable que actualice los recursos de tiempo de ejecución del cliente Faces a los últimos niveles.

    En Rational Application Developer V6.0.1, las actualizaciones de recursos de tiempo de ejecución de cliente Faces ocurren automáticamente cuando se importa un proyecto Web o se abre un área de trabajo que contiene recursos no actualizados. Después de importar un proyecto Web o abrir un área de trabajo de WebSphere Studio Application Developer V5.1.x a Rational Application Developer V6.0.1, se le solicitará actualizar los recursos de tiempo de ejecución del cliente Faces a los últimos niveles.

    Actualizar automáticamente recursos de tiempo de ejecución

    Para actualizar automáticamente los recursos de tiempo de ejecución del cliente Faces para un proyecto Web:

    1. Importe un proyecto Web (o un área de trabajo) con contenido de cliente Faces de WebSphere Studio Application Developer V5.1.x. Se abre la ventana Migración de proyectos.
      Nota:
      Si la ventana Migración de proyectos no se abre, el valor de preferencia de construcción automática esté probablemente inhabilitado. En el Explorador de proyecto, pulse con el botón derecho del ratón sobre el proyecto Web y seleccione Construir -> Proyecto; el proceso de reconstrucción de un proyecto abre la ventana Migración de proyectos.
    2. Si tiene otros proyectos Web con contenido de cliente Faces en el área de trabajo, marque Aplicar esta opción a cualesquiera otros proyectos que necesiten actualizarse y se actualizarán todos los proyectos Web.
    3. Pulse una de las opciones siguientes:
    4. En la carpeta Recursos Java -> JavaSource del proyecto Web, suprima todos los paquetes de clase de mediador de datos de cliente que sigan el convenio de denominación com.ibm.dynwdo4jsmediators.<client-data-name>. No suprima el paquete llamado com.ibm.dynwdo4jsmediators. Este paquete contiene metadatos (archivos ecore y emap) para los datos de cliente del proyecto que se utilizarán para regenerar los mediadores.
    5. En la carpeta Recursos Java -> JavaSource del proyecto Web, abra el archivo OdysseyBrowserFramework.properties y suprima las entradas para EMAP_FILES y ECORE_FILES.
    6. Para cada objeto de datos de la vista Datos de cliente:
      1. Pulse con el botón derecho del ratón y seleccione Configurar.
      2. En la pestaña Avanzadas, pulse Regenerar a partir de datos del lado del servidor para regenerar todos los mediadores para el objeto de datos.

    Actualizar manualmente recursos de tiempo de ejecución

    Para actualizar manualmente los recursos de tiempo de ejecución del cliente Faces para un proyecto Web:

    1. Siga los pasos de la sección Actualizar manualmente recursos de tiempo de ejecución de Actualizar recursos de tiempo de ejecución de Faces en un proyecto Web.
    2. Siga los pasos 4-6 de la sección anterior Actualizar automáticamente recursos de tiempo de ejecución.

    Pueden producirse problemas al cambiar el servidor destino de un proyecto que contenga componentes de cliente Faces de WebSphere Application Server V5.1 a V6.0.

    Hay dos problemas que pueden producirse al cambiar el servidor destino de un proyecto que contenga componentes de cliente Faces de WebSphere Application Server V5.1 a V6.0:

    Actualizar a los manejadores y procesadores Diff automatizados

    Los procesadores y los manejadores Diff se generan ahora automáticamente. Si escribió manejadores y procesadores Diff para los componentes de cliente Faces en WebSphere Studio V5.1.x, es recomendable descartar ese código y utilizar los procesadores y manejadores generados automáticamente:

    1. Genere los manejadores y procesadores Diff nuevos en cada objeto de datos de cliente en el proyecto Web.
      1. Seleccione el Objeto de datos de cliente, pulse con el botón derecho del ratón y seleccione Configurar.
      2. En la pestaña Avanzadas, pulse Regenerar todo.
    2. Elimine el código escrito para invocar los procesadores y manejadores Diff ya que los procesadores y manejadores generados se invocan automáticamente. Por ejemplo, este código se utiliza para el evento Command para el componente de botón de mandato:
      String Diff = getClientData1().getDiffStr();
      if (DiffProcessor.Synch(getRoot(), Diff) == true)
       return "";
      return "failure";
      
    3. Elimine del proyecto Web los archivos que corresponden a los manejadores y procesadores personalizados creados.

    Conservar los procesadores y los manejadores Diff personalizados escritos para V5.1.x

    Aunque esto no es recomendable, si decide que debe mantener los manejadores y procesadores Diff de V5.1.x, deberá modificarlos para que funcionen en V6.0 ya que la interfaz DiffHandler y la clase DiffInfo han cambiado.

    Cambios en los componentes de cliente Faces en V6.0:


    Migrar proyectos Web de Struts

    Para los proyectos Web de Struts creados en WebSphere Studio V5.1.x, debe realizar una pequeña modificación en el descriptor de despliegue del proyecto Web para poder ejecutar el proyecto EAR en WebSphere Application Server V6.0. También debe convertir manualmente los proyectos Webs de 1.0.2 o Struts 1.1 Beta (2 ó 3) a Struts 1.1.

    Modificar el descriptor de despliegue de los proyectos Web de Struts existentes

    Cuando se crea un proyecto Struts en WebSphere Studio v5.x, el parámetro config (<param-name>config</param-name>) del descriptor de despliegue del proyecto Web se establece en WEB-INF/struts-config.xml. Para WebSphere Application Server V6.0 es necesario que haya una barra inclinada inicial "/" en este parámetro. Si ejecuta un proyecto Web de Struts creado en WebSphere Studio V5.1.x en WebSphere Application Server V6.0, recibirá una excepción java.net.MalformedURLException al iniciar el proyecto EAR.

    Nota:
    Rational Application Developer V6.0 añadirá la barra inclinada "/" cuando se cree un proyecto Struts nuevo; sin embargo, debe añadirse manualmente al migrar de WebSphere Studio V5.1x.

    Siga estos pasos para corregir en V6.0 el descriptor de despliegue de un proyecto Web de Struts creado en WebSphere Studio v5.1.x:

    1. Abra el proyecto Web de Struts en el Explorador de proyectos.
    2. Efectúe una doble pulsación sobre el archivo Descriptor de despliegue Web del proyecto Web en el Explorador de proyectos. Se abre el editor del descriptor de despliegue Web.
    3. Pulse la pestaña Fuente para abrir la página Fuente.
    4. Cambie la línea

      <param-value>WEB-INF/struts-config.xml</param-value> (está ubicada entre los códigos <servlet></servlet>)

      por

      <param-value>/WEB-INF/struts-config.xml</param-value> .

    5. Guarde el descriptor de despliegue Web

    La excepción java.net.MalformedURLException no debe producirse cuando se reinicia el proyecto EAR.

    Convertir los proyectos Web de Struts 1.1 Beta a Struts 1.1

    En WebSphere Studio V5.1.x, la biblioteca de tiempo de ejecución Struts pasó de Struts 1.1 Beta (2 ó 3) en V5.0.x a Struts 1.1 (final). Si tiene proyectos Web de Struts 1.1 Beta (2 ó 3) y desea convertirlos a Struts 1.1 (final), puede hacerlo manualmente. (Nota: no es necesario convertir los proyectos de Struts 1.1 Beta (2 ó 3) a Struts 1.1. )

    Para convertir proyectos de Struts 1.1 Beta (2 ó 3) a Struts 1.1, haga lo siguiente:

    1. Cargue los proyectos de Struts 1.1 Beta en un entorno de trabajo de Rational Application Developer V6.0.
    2. Cree un proyecto Web de Struts 1.1 nuevo llamado, por ejemplo Struts11. Este proyecto temporal se crea para proporcionar un acceso cómodo a los archivos de tiempo de ejecución de Struts 1.1 que necesitará al convertir los proyectos reales. Puede suprimir este proyecto cuando haya terminado.
    3. Para cada proyecto de Struts 1.1 que desee convertir a Struts 1.1, haga lo siguiente:
      1. Suprima los archivos JAR siguientes del directorio Web Content/WEB-INF/lib del proyecto:
        • commons-*.jar.
        • struts.jar.
      2. Copie los archivos JAR siguientes del directorio Struts11/WebContent/WEB-INF/lib al directorio Web Content/WEB-INF/lib del proyecto:
        • commons-*.jar.
        • struts.jar.
      3. Suprima los archivos TLD (Descriptor de biblioteca de códigos) del directorio Web Content/WEB-INF del proyecto: struts-*.tld.
      4. Copie los archivos TLD siguientes del directorio Struts11/WebContent/WEB-INF al directorio Web Content/WEB-INF del proyecto: struts-*.tld.

    Convertir proyectos Web de Struts 1.0.2 a Struts 1.1

    En WebSphere Studio V5.1.x (y V5.0.x), al añadir soporte de Struts a un proyecto Web podía elegir Struts 1.0.2. Si tiene proyectos Web de Struts 1.0.2 existentes y desea convertirlos a Struts 1.1, puede convertirlos manualmente. (Nota: no es necesario convertir los proyectos de Struts 1.1 Beta (2 ó 3) a Struts 1.1. )

    Para convertir proyectos de Struts 1.0.2 a Struts 1.1, haga lo siguiente:

    1. Cargue los proyectos de Struts 1.0.2 en un área de trabajo de Rational Application Developer V6.0.
    2. Cree un proyecto Web de Struts 1.1 nuevo llamado, por ejemplo Struts11. Este proyecto temporal se crea para proporcionar un acceso cómodo a los archivos de tiempo de ejecución de Struts 1.1 que necesitará al convertir los proyectos reales. Puede suprimir este proyecto cuando haya terminado.
    3. Para cada proyecto de Struts 1.0.2 que desee convertir a Struts 1.1, haga lo siguiente:
      1. Suprima el archivo struts.jar del directorio Web Content/WEB-INF/lib del proyecto.
      2. Copie los archivos JAR siguientes del directorio Struts11/WebContent/WEB-INF/lib al directorio Web Content/WEB-INF/lib del proyecto:
        • commons-*.jar.
        • struts.jar.
        • jarkarta-oro.jar.
      3. Suprima los archivos TLD (Descriptor de biblioteca de códigos) del directorio Web Content/WEB-INF del proyecto: struts-*.tld.
      4. Copie los archivos TLD siguientes del directorio Struts11/WebContent/WEB-INF al directorio Web Content/WEB-INF del proyecto: struts-*.tld.

    Cambios que presenta el depurador en la V6.0

    Se han realizado cambios en las herramientas de depuración de Rational Application Developer V6.0. Deberá tener presentes esos cambios para poder utilizar las herramientas con los proyectos después de la migración. Es posible que deba cambiar o restaurar algunos valores.

    Migrar áreas de trabajo y configuraciones de lanzamiento

    Cuando un área de trabajo de la V5.1.x del producto WebSphere Studio Application Developer se abre en Rational Application Developer V6.0, hay unas cuantas configuraciones de lanzamiento del depurador asociadas al área de trabajo que no migrarán automáticamente; son las siguientes:

    Vistas de depuración

    Las vistas Almacenamiento y Correlación de almacenamiento han dejado de existir. En lugar de ellas se utilizan las vistas Memoria y Representación de la memoria.

    El depurador XSLT

    El depurador XSLT presenta cambios en la V6.0 y muchas de sus vistas y acciones han cambiado notablemente. Si desea obtener más información, vea la documentación del depurador XSLT, en Information Center.

    Uno de los cambios más significativos del depurador XSLT es la dependencia que tiene del JRE instalado con Rational Application Developer V6.0. Si migra un área de trabajo de WebSphere Studio Application Developer V5.1.x, tendrá que modificar el JRE instalado para que señale hacia la ubicación correcta para poder lanzar una sesión de depuración XSLT correspondiente a dicha área. Para ello, puede elegir una de estas acciones:


    Migración de WDO a SDO

    Si ha creado código en un proyecto Web cuyo servidor destino sea WebSphere Application Server V5.1 y que utilizaba registros relacionales o listas de registros relacionales de objetos de datos de WebSphere (WDO), cuando haga que el servidor destino de esas aplicaciones sea WebSphere Application Server V6.0, ahora utilizará registros relacionales y listas de registros relacionales de objetos de datos de servicio (SDO). La migración de WDO a SDO se produce automáticamente cuando cambia el servidor destino de la aplicación para que, en lugar de ser WebSphere Application Server V5.1, pase a ser WebSphere Application Server V6.0.

    El servidor destino se puede cambiar de dos formas:

    Los temas de ayuda que indican cómo cambiar el servidor destino y utilizar el asistente de migración J2EE están en la ayuda en línea de Rational Application Developer.

    Consideraciones sobre la compatibilidad

    Pueden producirse errores de conflicto de tipos después de la migración de WDO a SDO

    Después de migrar un proyecto que utilice WDO a un proyecto basado en SDO, si añade datos SDO a una página JSP existente que tenga datos WDO existentes, pueden producirse errores de conflicto de tipos. Esto sucede debido a la mezcla de beans de acceso WDO existentes y API SDO autónomas. Por ejemplo, puede ver un error de compilación en el archivo fuente Java del JSP parecido al siguiente:

    import com.ibm.websphere.sdo.mediator.exception.MediatorException
    presenta un conflicto con otro tipo importado
    

    Estos errores de conflicto de tipos pueden corregirse de la forma siguiente:

    1. Elimine la sentencia de importación en conflicto del archivo fuente Java. Utilizando el ejemplo anterior, puede eliminar la sentencia de importación siguiente del archivo fuente:
      import com.ibm.websphere.wdo.mediator.exception.MediatorException;
      
    2. Modifique el archivo fuente Java que hace referencia al tipo para utilizar el nombre de clase totalmente calificado. Basándose en el ejemplo anterior, el tipo MediatorException debe cambiarse por com.ibm.websphere.wdo.mediator.exception.MediatorException. Por ejemplo, el código fuente
      catch ( MediatorException e1 ) {
      

      debe cambiarse por

      catch ( com.ibm.websphere.wdo.mediator.exception.MediatorException e1 ) {
      

    Cambios realizados en un proyecto Web después de cambiar el servidor destino de V5.1 a V6.0 (de WDO a SDO)

    Cuando el servidor destino cambia de V5.1 a V6.0, se realizan automáticamente los siguientes cambios:

    Cambios realizados en un proyecto Web después de cambiar el destino de servidor de V6.0 a V5.1 (de SDO a WDO)

    Cuando el servidor destino cambia de V6.0 a V5.1, se realizan automáticamente los siguientes cambios:

    Cambios realizados en un proyecto Web después de hacer que el nivel J2EE de la aplicación cambie de 1.3 a 1.4

    Además de los cambios que se producen para migrar de WDO a SDO al cambiar el destino de servidor para que sea WebSphere Application Server V6.0, el hecho de hacer que el nivel de especificación J2EE de la aplicación cambie de 1.3 a 1.4 provoca que se actualicen las referencias de las bibliotecas de códigos (taglib) de los archivos JavaServer Pages (JSP), ya que, en vez de utilizar las bibliotecas de códigos de WDO, JSTL 1.0, se utilizarán las bibliotecas de códigos de SDO, JSTL 1.1/JSP 2.0. En la siguiente tabla verá los cambios que se producen en las referencias de las bibliotecas de códigos JSP cuando se pasa de J2EE 1.3 a J2EE 1.4.


    Tabla 1. Referencias de las bibliotecas de códigos JSP en J2EE 1.3 y J2EE 1.4

    Biblioteca de códigos de J2EE 1.3 (WDO) Biblioteca de códigos de J2EE 1.4 (SDO)
    http://www.ibm.com/websphere/wdo/core http://www.ibm.com/websphere/sdo/core
    http://java.sun.com/jstl/core http://java.sun.com/jsp/jstl/core
    http://java.sun.com/jstl/fmt http://java.sun.com/jsp/jstl/fmt
    http://java.sun.com/jstl/xml http://java.sun.com/jsp/jstl/xml
    http://java.sun.com/jstl/sql http://java.sun.com/jsp/jstl/sql

    Palabras reservadas del EGL en V6.0

    En Rational Application Developer, hay nuevas palabras reservadas en el lenguaje de generación para empresas (EGL).

    Las nuevas palabras reservadas son las siguientes:

    Los programas EGL de WebSphere Studio V5.1.x que se importen y construyan en un área de trabajo de V6.0 y que utilicen estas palabras como nombres de variables o componentes se señalarán con el siguiente mensaje: IWN.SYN.2002.e 39/2 Error de sintaxis en "variableName" de entrada. Este problema se corrige cambiando el nombre de la variable.


    Capítulo 2. Actualizar recursos de tiempo de ejecución de Faces para proyectos Web de Rational Application Developer V6.0

    Los recursos de tiempo de ejecución de Faces y cliente Faces enviados originalmente en Rational Application Developer V6.0 se han actualizado para Rational Application Developer V6.0.1. Si desea seguir desarrollando proyectos Web creados con esta versión anterior del producto, es recomendable que actualice los recursos de tiempo de ejecución de Faces y del cliente Faces a los últimos niveles.

    En Rational Application Developer V6.0.1, las actualizaciones de recursos de tiempo de ejecución de Faces y del cliente Faces ocurren automáticamente cuando se importa un proyecto Web o se abre un área de trabajo que contiene recursos no actualizados. Después de importar un proyecto Web o abrir un área de trabajo de Rational Application Developer V6.0.x a Rational Application Developer V6.0.1, se le solicitará actualizar estos recursos de tiempo de ejecución a los últimos niveles.

    Actualizar automáticamente recursos de tiempo de ejecución

    Para actualizar automáticamente los recursos de tiempo de ejecución de Faces y del cliente Faces para un proyecto Web:

    1. Importe un proyecto Web (o un área de trabajo) con contenido de Faces o de cliente Faces de Rational Application Developer V6.0. Se abre la ventana Migración de proyectos.
      Nota:
      Si la ventana Migración de proyectos no se abre, el valor de preferencia de construcción automática esté probablemente inhabilitado. En el Explorador de proyecto, pulse con el botón derecho del ratón sobre el proyecto Web y seleccione Construir -> Proyecto; el proceso de reconstrucción de un proyecto abre la ventana Migración de proyectos.
    2. Si tiene otros proyectos Web con contenido de Faces o del cliente Faces en el área de trabajo, marque Aplicar esta opción a cualesquiera otros proyectos que necesiten actualizarse y se actualizarán todos los proyectos Web.
    3. Pulse una de las opciones siguientes:

    Actualizar manualmente recursos de tiempo de ejecución

    Para actualizar manualmente los recursos de tiempo de ejecución de Faces y del cliente Faces para un proyecto Web:

    1. Cree un proyecto Web nuevo (o si está trabajando con EGL, cree un proyecto Web de EGL nuevo) llamado JSF601. Este proyecto tan solo lo utilizará como origen de los recursos de tiempo de ejecución más recientes; puede suprimirse una vez realizada la actualización.
    2. En el explorador de proyectos, pulse el proyecto JSF601 con el botón derecho del ratón y seleccione Propiedades en el menú.
    3. Pulse Características de proyecto Web y seleccione Añadir componentes de base Faces y Añadir infraestructura de cliente Faces y pulse Aceptar.
    4. Si está trabajando con EGL, cree un archivo de página JSF de la forma siguiente:
      1. Pulse el botón derecho del ratón sobre la carpeta WebContent del proyecto Web EGL nuevo.
      2. Seleccione Nuevo -> Otros -> Archivo JSP Faces.
      Los archivos eglintdebug.jar y eglintdebugsupport.jar se añaden al proyecto.
    5. Para cada proyecto Faces existente que desee actualizar, haga lo siguiente:
      1. Expanda un proyecto existente en el Explorador de proyectos para ver los archivos que hay en la carpeta WebContent/WEB-INF/lib/. En este directorio, localice cada uno de los siguientes archivos JAR y suprímalos:
        • eglintdebug.jar (solo EGL)
        • eglintdebugsupport.jar (solo EGL)
        • fda6.jar (solo EGL)
        • fdaj6.jar (solo EGL)
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • odc-jsf.jar
      2. Por cada uno de los archivos JAR que suprimió, copie el archivo JAR que tenga el mismo nombre en el directorio WebContent/WEB-INF/lib del proyecto JSF601 y péguelo en el proyecto original en la misma ubicación. En algunas configuraciones no hará falta que todos estos archivos JAR estén presentes en el proyecto; no copie un archivo JAR determinado si no estaba en el proyecto original.
      3. Si está trabajando con EGL, pulse con el botón derecho del ratón sobre el nombre de cada proyecto Web EGL y pulse Generar; si no está construyendo los proyectos automáticamente, pulse Proyecto -> Construir todo.
    6. Suprima el proyecto Web JSF601.

    Capítulo 3. Actualizar recursos de tiempo de ejecución de Faces para proyectos de portlet de Rational Application Developer V6.0

    Los recursos de tiempo de ejecución de JavaServer Faces y el cliente Faces enviados originalmente en Rational Application Developer V6.0 se han actualizado para Rational Application Developer V6.0.1. Si desea seguir desarrollando proyectos de portlet creados con esta versión anterior del producto, es recomendable que actualice los recursos de tiempo de ejecución de Faces y del cliente Faces a los últimos niveles.

    En Rational Application Developer V6.0.1, las actualizaciones de los recursos de tiempo de ejecución de Faces y del cliente Faces se producen automáticamente cuando se importa un proyecto de portlet o se abre un área de trabajo que contiene recursos de Faces o del cliente Faces no actualizados. Después de importar un proyecto de portlet o de abrir un área de trabajo de Rational Application Developer V6.0 en Rational Application Developer V6.0.1, se le solicitará actualizar estos recursos de tiempo de ejecución a los niveles más recientes.

    Actualizar automáticamente recursos de tiempo de ejecución

    Para actualizar automáticamente los recursos de tiempo de ejecución de Faces y del cliente Faces para un proyecto de portlet:

    1. Importe un proyecto de portlet (o un área de trabajo) con contenido de Faces o del Cliente Faces de Rational Application Developer V6.0. Se abre la ventana Migración de proyectos.
      Nota:
      Si la ventana Migración de proyectos no se abre, el valor de preferencia de construcción automática esté probablemente inhabilitado. En el Explorador de proyecto, pulse con el botón derecho del ratón sobre el proyecto de portlet y seleccione Construir -> Proyecto; el proceso de reconstrucción de un proyecto abre la ventana Migración de proyectos.
    2. Si tiene otros proyectos de portlet con contenido de Faces o del cliente Faces en el área de trabajo, marque Aplicar esta opción a cualesquiera otros proyectos que necesiten actualizarse y se actualizarán todos los proyectos de portlet.
    3. Pulse una de las opciones siguientes:
    4. Para actualizar los recursos de tiempo de ejecución Faces específicos del portlet, jsf-portlet.jar y jsf-wp.jar, debe seguir los pasos de actualización manual que se indican a continuación.

    Actualizar manualmente recursos de tiempo de ejecución

    Para actualizar manualmente los recursos de tiempo de ejecución de Faces y del cliente Faces para un proyecto de portlet:

    1. Cree un proyecto de portlet nuevo llamado JSFP601. Este proyecto tan solo lo utilizará como origen de los recursos de tiempo de ejecución más recientes; puede suprimirse una vez realizada la actualización.
    2. En el explorador de proyectos, pulse el proyecto JSFP601 con el botón derecho del ratón y seleccione Propiedades en el menú.
    3. Pulse Características de proyecto Web, seleccione Añadir infraestructura de cliente Faces para proyecto de portlet y pulse Aceptar.
    4. Para cada proyecto de portlet Faces existente que desee actualizar, haga lo siguiente:
      1. Expanda un proyecto existente en el Explorador de proyectos para ver los archivos que hay en la carpeta WebContent/WEB-INF/lib/. En este directorio, localice cada uno de los siguientes archivos JAR y suprímalos:
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • jsf-portlet.jar
        • odc-jsf.jar
      2. Por cada uno de los archivos JAR que suprimió, copie el archivo JAR que tenga el mismo nombre en el directorio WebContent/WEB-INF/lib del proyecto JSFP601 y péguelo en el proyecto original en la misma ubicación. En algunas configuraciones no hará falta que todos estos archivos JAR estén presentes en el proyecto; no copie un archivo JAR determinado si no estaba en el proyecto original.
        • Si el proyecto portlet utiliza la API de portlet de IBM o un componente de enlace personal, copie el archivo jsf-wp.jar en el proyecto original.
        • Si copia el archivo odc-jsf.jar, copie asimismo el archivo odc-jsf-portlet.jar.
    5. Suprima el proyecto de portlet JSFP601.

    Capítulo 4. Migrar proyectos J2EE

    El asistente de migración J2EE se ha actualizado en Rational Application Developer V6.0 para migrar los proyectos J2EE al nivel de especificación J2EE 1.4. El asistente de migración J2EE permite migrar de las especificaciones J2EE 1.2 y 1.3 al nivel de especificación J2EE 1.4. sea cual sea el tipo de módulo J2EE.

    Los detalles sobre cómo migrar artefactos de los niveles de especificación J2EE 1.2 y 1.3 al nivel de especificación J2EE 1.4 están en: Migración del nivel de especificación J2EE 1.2 al nivel de especificación J2EE 1.4 y Migración del nivel de especificación J2EE 1.3 al nivel de especificación J2EE 1.4.

    Nota:
    Antes de utilizar el asistente de migración J2EE, le recomendamos encarecidamente que tome las siguientes medidas:

    Para acceder al asistente de migración J2EE, siga estos pasos:

    1. En la vista Jerarquía J2EE de la perspectiva J2EE, pulse con el botón derecho del ratón el proyecto de aplicación de empresa que desea migrar.
    2. En el menú emergente, seleccione Migrar -> Asistente de migración J2EE.
    3. Siga las instrucciones de la página de bienvenida del asistente de migración J2EE antes de seguir adelante con el proceso de migración.

    Nota:

    En la ayuda en línea hallará todos los detalles de cómo utilizar el asistente de migración J2EE. Los cambios que presenta el asistente se describen en: Cambios que presenta el asistente de migración J2EE en Rational Application Developer V6.0.

    Para obtener los detalles sobre los cambios que se realizan en los artefactos de los niveles de especificación J2EE 1.3 y J2EE 1.2 cuando se migran a J2EE 1.4, consulte: Migración del nivel de especificación J2EE 1.3 al nivel de especificación J2EE 1.4 y Migración del nivel de especificación J2EE 1.2 al nivel de especificación J2EE 1.4.


    Migrar servicios Web seguros

    El asistente de migración J2EE no migra los servicios Web seguros al migrar los servicios Web de J2EE 1.3 a J2EE 1.4. Para migrar los servicios Web seguros hay que realizar varios pasos manuales.

    Después del proceso de migración J2EE, los archivos de enlace y extensión seguros se deben migrar manualmente a J2EE 1.4, de la siguiente manera:

    1. Pulse dos veces en el archivo webservices.xml para abrir el editor de servicios Web.
    2. Seleccione la pestaña Configuraciones de enlace para editar el archivo de enlace.
    3. Añada todas las configuraciones de enlace necesarias en las nuevas secciones de detalles de configuración de enlace de consumidor de peticiones y detalles de configuración de enlace de generador de respuestas.
    4. Seleccione la pestaña Extensión para editar el archivo de extensión.
    5. Añada todas las configuraciones de extensión necesarias en las nuevas secciones de detalles de configuración de servicio de consumidor de peticiones y detalles de configuración de servicio de generador de respuestas.
    6. Guarde los cambios y salga del editor.

    Migración del nivel de especificación J2EE 1.3 al nivel de especificación J2EE 1.4

    Los proyectos J2EE se pueden migrar del nivel de especificación J2EE 1.3 al nivel de especificación J2EE 1.4. En este apartado, para cada tipo de proyecto J2EE, se describen los artefactos que el asistente de migración J2EE migra de J2EE 1.3 a J2EE 1.4.

    Proyectos Enterprise JavaBean (de EJB 2.0 a EJB 2.1)

    El asistente de migración J2EE permite migrar los descriptores de despliegue de beans de empresa de los recursos EJB del nivel de especificación J2EE 1.3 al nivel de especificación J2EE 1.4. Los beans de sesión sin estado y los beans controlados por mensajes migran a J2EE 1.4.

    Migrar beans de sesión

    Con el asistente de migración J2EE, los beans de sesión sin estado que estén definidos como interfaces de punto final de servicio (SEI) en el descriptor webservices.xml de un proyecto EJB en J2EE 1.3 se pueden migrar al nivel de especificación J2EE 1.4, estableciéndose para ello nuevas interfaces de punto final de servicio en los beans de sesión sin estado.

    La especificación J2EE 1.4 exige que se defina una SEI en un bean de sesión sin estado que deba utilizarse como punto final de servicios Web. Durante la migración de un archivo JAR EJB, todos los beans de sesión del proyecto EJB obtienen el nuevo punto final de servicio establecido en el nombre que se utiliza en el descriptor webservices.xml del proyecto EJB. En el siguiente ejemplo, se ve cómo son los metadatos de un proyecto EJB antes y después de migrarlo al nivel de especificación J2EE 1.4.

    Proyecto EJB de J2EE 1.3: descriptor webservices.xml con un bean de sesión sin estado que se utiliza como punto final de servicios Web antes de la migración

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE webservices PUBLIC "-//IBM Corporation, Inc.//DTD J2EE Web services 1.0//EN" 
    "http://www.ibm.com/webservices/dtd/j2ee_web_services_1_0.dtd">
       <webservices id="WebServices_1084831328093">
          <webservice-description id="WebServiceDescription_1084831328093">
             <webservice-description-name>EchoEJBService</webservice-description-name>
             <wsdl-file>META-INF/wsdl/EchoEJB.wsdl</wsdl-file>
             <jaxrpc-mapping-file>META-INF/EchoEJB_mapping.xml</jaxrpc-mapping-file>
             <port-component id="PortComponent_1084831328103">
                <port-component-name>EchoEJB</port-component-name>
                <wsdl-port id="WSDLPort_1084831328103">
                   <namespaceURI>http://test</namespaceURI>
                   <localpart>EchoEJB</localpart>
                </wsdl-port>
                <service-endpoint-interface>test.EchoEJB</service-endpoint-interface>
                <service-impl-bean id="ServiceImplBean_1084831328103">
                   <ejb-link>EchoEJB</ejb-link>
                </service-impl-bean>
             </port-component>
          </webservice-description>
       </webservices>
    

    Los códigos <service-endpoint-interface> y <service-impl-bean> del ejemplo anterior definen el bean de sesión sin estado "EchoEJB" como punto final de servicio en el descriptor de servicios Web (webservices) en el nivel de especificación J2EE 1.3 antes de la migración.

    Proyecto EJB de J2EE 1.4: descriptor de despliegue EJB del mismo bean de sesión sin estado "EchoEJB" con la interfaz de punto final de servicio (SEI) creada por el proceso de migración

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE ejb-jar>
    <ejb-jar id="ejb-jar_ID" version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
    	<display-name>
    	EchoEJBProject</display-name>
    	<enterprise-beans>
    		<session id="EchoEJB">
    			<ejb-name>EchoEJB</ejb-name>
    			<home>test.EchoEJBHome</home>
    			<remote>test.EchoEJB</remote>
    			<service-endpoint>test.EchoEJB</service-endpoint>
    			<ejb-class>test.EchoEJBBean</ejb-class>
    			<session-type>Stateless</session-type>
    			<transaction-type>Container</transaction-type>
    		</session>
    	</enterprise-beans>
    </ejb-jar>
    

    El código <service-endpoint> del ejemplo anterior define el bean "EchoEJB" como punto final de servicio en el nivel de especificación J2EE 1.4 después de la migración.

    Migrar beans controlados por mensajes

    El asistente de migración de J2EE soporta la migración de beans controlados por mensaje de EJB 2.0 a EJB 2.1.

    Los beans controlados por mensajes se introdujeron en EJB 2.0 para dar soporte al proceso de mensajes asíncronos procedentes de un servicio de mensajería Java (JMS). La especificación EJB 2.1 amplía la definición del bean controlado por mensajes para que pueda admitir cualquier sistema de mensajería, no tan solo el sistema JMS.

    Nota:
    Los beans controlados por mensaje que se han migrado del nivel de especificación EJB 2.0 a EJB 2.1 y que se despliegan en WebSphere Application Server Versión 6 deben desplegarse contra un recurso de JCA (Java Connector Architecture) 1.5 en lugar de un puerto de escucha (como en WebSphere Application Server Versión 5). Debe utilizar el Editor de descriptores de despliegue para cambiar los valores de Enlaces de WebSphere para que los beans controlados por mensaje de EJB 2.1 utilicen un adaptador JCA. Consulte Configurar un bean controlado por mensaje de EJB 2.1 para que utilice un adaptador JCA.

    Los artefactos migrados de los beans controlados por mensajes de EJB 2.0 son:

    Algunos de los elementos de los beans controlados por mensajes de EJB 2.0 se sustituyen por propiedades del elemento activation-config. Los nombres y valores que se utilizan en la propiedad activation-config para describir el servicio de mensajería varía en función del tipo de servicio de mensajería que se utilice. Sin embargo, la especificación EJB 2.1 define un conjunto de propiedades fijas para los beans controlados por mensajes basados en JMS.

    En el siguiente ejemplo, se establece una comparación entre los elementos de un bean de ejemplo de EJB 2.0 y los elementos tal como serían en EJB 2.1.

    Ejemplo de los elementos de un bean controlado por mensajes en EJB 2.0:

    <message-driven id="Mdb20">
    	  <ejb-name>Mdb</ejb-name>
    	  <ejb-class>ejbs.MdbBean</ejb-class>
    	  <transaction-type>Bean</transaction-type>
    	  <message-selector>mdbMessage</message-selector>
    	  <acknowledge-mode>Auto-acknowledge</acknowledge-mode>
    	  <message-driven-destination>
    		<destination-type>javax.jms.Topic</destination-type>
    		<subscription-durability>Durable</subscription-durability>
    	   </message-driven-destination>
    </message-driven>
    

    Ejemplo de los elementos de un bean controlado por mensajes en EJB 2.1:

        <message-driven id="Mdb21">
      <ejb-name>Foo/ejb-name>
      <ejb-class>ejbs.FooBean</ejb-class>
       <messaging-type>javax.jms.MessageListener</messaging-type>
       <transaction-type>Bean/transaction-type>
       <message-destination-type>javax.jms.Topic</message-destination-type>
        <activation-config>
    	  <activation-config-property>
    	   <activation-config-property-name>destinationType</activation-config-property-name>
    	   <activation-config-property-value>javax.jms.Topic</activation-config-property-value>
    	  </activation-config-property>
    	  <activation-config-property>
    	   <activation-config-property-name>subscriptionDurability</activation-config-property-name>
    	     <activation-config-property-value>Durable</activation-config-property-value>
    	  </activation-config-property>
    	  <activation-config-property>
    	     <activation-config-property-name>acknowledgeMode</activation-config-property-name>
    	     <activation-config-property-value>AutoAcknowledge</activation-config-property-value>
    	  </activation-config-property>
    	  <activation-config-property>
    		<activation-config-property-name>messageSelector</activation-config-property-name>
    		<activation-config-property-value>fooSelector</activation-config-property-value>
    	  </activation-config-property>
    </activation-config>
    </message-driven>
    

    Configurar un bean controlado por mensaje de EJB 2.1 para que utilice un adaptador JCA

    Los beans controlados por mensaje que se han migrado del nivel de especificación Enterprise Java Bean (EJB) 2.0 al EJB 2.1 y que se despliegan en WebSphere Application Server Versión 6 deben desplegarse contra un adaptador de recursos Java Connector Architecture (JCA) 1.5 en lugar de un puerto de escucha.

    Los pasos siguientes describen cómo cambiar el descriptor de despliegue de los beans controlados por mensaje de EJB 2.1 para que utilicen un adaptador JCA:

    1. Abra el proyecto EJB en el Explorador de proyectos.
    2. Efectúe una doble pulsación sobre el archivo Descriptor de despliegue del proyecto EJB en el Explorador de proyectos. Se abre el editor de descriptores de despliegue EJB.
    3. Pulse la pestaña Bean para abrir la página Bean.
    4. Para cada bean controlado por mensaje EJB 2.1 del proyecto EJB, haga lo siguiente:
      1. Seleccione el bean gestionado por mensaje EJB 2.1 en la lista de beans del lado izquierdo de la página Bean.
      2. Bajo la cabecera de Enlaces de WebSphere, seleccione el botón Adaptador de JCA.
      3. Especifique las propiedades de despliegue de los enlaces:
        1. Nombre JNDI de ActivationSpec.

          Teclee el nombre JNDI de la especificación de activación J2C que debe utilizarse para desplegar este bean controlado por mensaje. Este nombre debe coincidir con el nombre de una especificación de activación J2C definida en WebSphere Application Server.

        2. Alias de autorización de ActivationSpec.

          El nombre de un alias de autenticación J2C utilizado para la autenticación de conexiones con el adaptador de recursos de JCA. Un alias de autenticación J2C especifica el ID de usuario y la contraseña utilizados para autenticar la creación de una conexión nueva con el adaptador de recursos JCA.

        3. Nombre JNDI de destino.

          Teclee el nombre JNDI que el bean controlado por mensaje utiliza para buscar el destino JMS en el espacio de nombres JNDI.

    5. Guarde los cambios y cierre el editor de descriptores de despliegue.

    Proyectos Web (del nivel Servlet 2.3 al nivel Servlet 2.4)

    El asistente de migración J2EE migra los artefactos de un descriptor de despliegue Web cuando se migra un proyecto Web del nivel J2EE 1.3 al nivel J2EE 1.4.

    Los artefactos de aplicaciones Web que migran son:

    Restricciones de autenticación

    En J2EE 1.4 existe un objeto Description que consta de dos atributos: language y value. El objeto Description no existía en J2EE 1.3; la descripción era un atributo de la restricción de autenticación. Por lo tanto, cuando los artefactos de un descriptor de despliegue Web migran a J2EE 1.4, el atributo value del objeto Description se obtiene del atributo description de la restricción de autenticación.

    Restricciones de seguridad

    De manera parecida, en J2EE 1.3, la descripción era un atributo de la restricción de seguridad. En J2EE 1.4, existe un nuevo objeto Description que tiene los atributos language y value. Por lo tanto, el atributo value del objeto Description se obtiene del atributo description de la restricción de seguridad.

    Aplicación Web

    La serie del atributo description del objeto ContextParam en el nivel de especificación J2EE 1.3 se ha trasladado a un objeto Description de ParamValue en J2EE 1.4.

    El objeto TagLib existente en J2EE 1.3 se ha trasladado al objeto JSPConfig en J2EE 1.4. Los objetos JSPConfig pertenecían al objeto raíz Web en J2EE 1.3.

    Proyectos de conector (de JCA 1.0 a JCA 1.5)

    El asistente de migración J2EE permite migrar los artefactos de un descriptor de la arquitectura de conectores J2EE (JCA) 1.0 a la arquitectura de conectores J2EE (JCA) 1.5. Los artefactos migrados están relacionados con los elementos del objeto ResourceAdaptor porque se añadieron dos objetos nuevos, OutboundResourceAdaptor y ConnectionDefinition, al objeto ResourceAdaptor en el nivel de especificación J2EE 1.4 para los proyectos de conector.

    La correlación de los elementos migrados se describe más abajo.

    Servicios Web (de J2EE 1.3 a J2EE 1.4)

    La especificación J2EE 1.4 ha añadido soporte para los servicios Web mediante la nueva API JAX-RPC 1.0.

    La API JAX-RPC da soporte a los puntos finales de servicio mediante:

    La especificación J2EE 1.4 da soporte a los servicios Web correspondientes a la especificación J2EE (JSR 109). JSR 109 define los requisitos de despliegue de los servicios Web y utiliza el modelo de programación JAX-RPC.

    Los artefactos de servicios Web que migran mediante el asistente de migración J2EE son:

    Migrar descriptores de despliegue de servicios Web

    Los descriptores de despliegue de servicios Web que estén contenidos en proyectos de J2EE 1.3 migrados al nivel de especificación J2EE 1.4 migrarán de JSR-109 V1.0 (para J2EE 1.3) a J2EE 1.4.

    Los descriptores de despliegue de servicios Web, tal como están definidos en JSR-109 V1.0, constan de los archivos webservices.xml, webservicesclient.xml y de todos los descriptores de despliegue de correlación JAX-RPC a los que hagan referencia los archivos webservices.xml y webservicesclient.xml. Al igual que con los otros descriptores de despliegue J2EE, la migración modificará la estructura de la información contenida en los descriptores para que estén en conformidad con la especificación J2EE 1.4. Uno de los cambios estructurales que es específico de los descriptores de despliegue de servicios Web es el que se produce en la manera de representar los nombres calificados. En JSR-109 V1.0, los nombres calificados se representan mediante una secuencia de dos elementos, <namespaceURI> y <localpart>, los cuales contienen el URI del espacio de nombres y el componente local del nombre, respectivamente. En J2EE 1.4, los nombres calificados se basan en el tipo de nombre calificado del esquema XML, que utiliza espacios de nombres XML.

    A continuación se dan más detalles sobre la migración de cada uno de los descriptores de despliegue de servicios Web.


    Migración del nivel de especificación J2EE 1.2 al nivel de especificación J2EE 1.4

    Los módulos J2EE se pueden migrar del nivel de especificación J2EE 1.2 al nivel de especificación J2EE 1.4. En este apartado se describen los artefactos de los proyectos J2EE que el asistente de migración J2EE migra del nivel de especificación J2EE 1.2 al nivel de especificación J2EE 1.4.

    Los detalles de cómo utilizar el asistente de migración J2EE están en: Capítulo 4, Migrar proyectos J2EE.

    Migrar proyectos JavaBeans (de EJB 1.1 a EJB 2.1)

    En este apartado se explica cómo migrar un proyecto EJB del nivel de especificación EJB 1.1 al nivel de especificación EJB 2.1.

    Para migrar un proyecto EJB de EJB 1.1 a EJB 2.1, hay que migrar los beans de entidad con persistencia gestionada por contenedor (CMP).

    No se han realizado cambios en los beans de entidad entre los niveles de especificación J2EE 1.3 y J2EE 1.4. Para migrar los beans de entidad CMP del nivel de especificación EJB 1.1 al nivel de especificación EJB 2.1 se sigue el mismo procedimiento que para migrar un bean de entidad CMP de EJB 1.1 a EJB 2.0. Para migrar beans de entidad gestionados por contenedor del nivel de especificación EJB 1.1 al nivel de especificación EJB 2.x, se realizan estos pasos:

    1. Convertir el proyecto EJB de EJB 1.1 a EJB 2.x.
    2. Migrar el código EJB de EJB 1.1 a EJB 2.x.
    3. Migrar las referencias que estén definidas por usuario en EJB 1.1 a referencias locales de EJB 2.x.

    Convertir proyectos de EJB 1.1 a EJB 2.x

    Los proyectos de EJB 1.1 se pueden convertir a proyectos de EJB 2.x con el asistente de migración J2EE.

    O bien, si desea conservar el proyecto original de EJB 1.1, puede crear un proyecto nuevo en EJB 2.x y después importar a este el archivo JAR del proyecto existente (Archivo -> Importar -> JAR EJB).

    Aunque el proyecto sea un proyecto de EJB 2.x, los beans de entidad con persistencia gestionada por contenedor (CMP) de EJB 1.1 existentes o importados siguen siendo beans de EJB 1.1. Es decir, los beans de entidad CMP no se convierten a EJB 2.x.

    El asistente de migración J2EE hace que los beans de empresa de un proyecto de EJB 2.x migren de 1.1 a 2.x. (Si opta por migrar los beans de entidad CMP de 1.1 a 2.x, hay que migrar todos los beans del proyecto de 2.x. Sin embargo, puede optar por añadir selectivamente vistas de cliente local a estos beans de 2.x migrados).

    Nota:
    Si tiene asociaciones correlacionadas, se crearán asociaciones de EJB 2.x para las propias asociaciones, pero las correlaciones de cometidos de las asociaciones pasarán a no ser válidas. Si ejecuta la validación, observará que se produce un error. Para salir de esta situación, abra primero el editor de correlaciones y guarde la correlación. Las correlaciones de cometidos se eliminarán. Entonces podrá ejecutar de nuevo la validación y volver a correlacionar los cometidos.

    Migrar código de EJB 1.1 a EJB 2.x

    En el caso de los proyectos que se conviertan de EJB 1.1 a EJB 2.x, hay que realizar unos cuantos pasos para migrar el código existente en EJB 1.1 a EJB 2.x.

    Nota:
    Los beans de EJB 2.x solo se pueden utilizar en un proyecto de EJB 2.x (aunque en un proyecto de 2.x también se pueden utilizar beans de 1.1).

    1. Para los beans CMP de 1.1, sustituya cada campo CMP por los métodos abstractos getXXX y setXXX. (Por lo tanto, la clase de bean también debe ser abstracta).
    2. Para los CMP, cree un método abstracto getXXX y setXXX para la clave primaria.
    3. Para los métodos de búsqueda CMP de 1.1, cree un método EJBQL (lenguaje de consulta EJB) para cada método de búsqueda.
      Nota:
      El lenguaje de consulta EJB tiene las siguientes limitaciones en Rational Application Developer V6.0:
      • Las consultas del lenguaje de consulta EJB en las que intervienen beans EJB con claves que se componen de relaciones con otros beans EJB no resultarán válidas y provocarán errores en el momento del despliegue.
      • El soporte del lenguaje de consulta EJB de IBM amplía la especificación EJB 2.x de diversas maneras, entre ellas las de relajar algunas restricciones, añadir soporte para más funciones de DB2, etcétera. Si le interesa la portabilidad entre las bases de datos de diversos proveedores o entre las herramientas de despliegue EJB, tendrá que tener cuidado de escribir todas las consultas del lenguaje de consulta EJB de forma que estén estrictamente de acuerdo con las instrucciones indicadas en el capítulo 11 de la especificación EJB 2.x.
    4. Para los métodos de búsqueda CMP de 1.1, devuelva java.util.Collection, en lugar de java.util.Enumeration.
    5. Para los beans CMP de 1.1, cambie todas las apariciones de this.field = value por setField(value) en el método ejbCreate() y en cualquier otra parte del código.
    6. Actualice el manejo de excepciones (comportamiento de la retrotracción) para las excepciones que no sean de la aplicación:
    7. Actualice el manejo de excepciones (comportamiento de la retrotracción) para las excepciones de la aplicación:
    8. Actualice los valores CMP de los valores predeterminados específicos de la aplicación para que estén dentro de ejbCreate (no lo haga utilizando variables globales, porque los contenedores de EJB 1.1 establecen todos los campos en valores predeterminados genéricos antes de llamar a ejbCreate, que sobrescribirá los valores predeterminados anteriores que sean específicos de la aplicación).

    Migrar las referencias de EJB para las relaciones de EJB 1.1

    Al crear relaciones de EJB 1.1, se crearon referencias de EJB a la vista de cliente remoto. Durante la migración del proyecto EJB 1.1 mediante el asistente de migración J2EE, estas referencias remotas de EJB correspondientes a las relaciones de EJB 1.1 se eliminan y se sustituyen por referencias locales de EJB. Las referencias locales correspondientes a las referencias de EJB definidas por el usuario se tienen que volver a crear manualmente.

    Nota:
    En EJB 2.x, solo se pueden crear relaciones de EJB si los beans tienen definida la vista de cliente local y se crean las referencias locales de EJB para las relaciones de EJB 2.x.

    En el caso de las referencias de EJB definidas por usuario, la migración no se realiza mediante el asistente de migración J2EE. Sin embargo, para configurar las referencias locales, siga estos pasos:

    1. Suprima las referencias remotas de EJB existentes en la página Referencias del editor de descriptores de despliegue.
    2. Añada una referencia local de EJB en la página Referencias del editor de descriptores de despliegue.

    Los elementos de método se fusionan durante la migración de la estructura del proyecto

    Durante la migración de la estructura del proyecto mediante el asistente de migración J2EE, los elementos de método (como son la identidad de seguridad, la transacción de contenedor, los permisos de método, el propósito de acceso y los niveles de aislamiento) que sean del mismo tipo para todos los beans se fusionan para formar un grupo lógico.

    A continuación figura un ejemplo de los elementos de método antes y después de la migración de la estructura del proyecto.

    Este es un ejemplo del permiso de método (method-permission) en la página de código fuente del editor de descriptores de despliegue antes de migrar la estructura del proyecto.

    		<method-permission>
    			<role-name>rol1</role-name>
    			<role-name>rol2</role-name>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getEJBMetaData</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getHomeHandle</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>remove</method-name>
    				<method-params>
    					<method-param>java.lang.Object</method-param>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>remove</method-name>
    				<method-params>
    					<method-param>javax.ejb.Handle</method-param>
    				</method-params>
    			</method>
    		</method-permission>
    		<method-permission>
    			<role-name>rol1</role-name>
    			<role-name>rol2</role-name>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Remote</method-intf>
    				<method-name>isIdentical</method-name>
    				<method-params>
    					<method-param>javax.ejb.EJBObject</method-param>
    				</method-params>
    			</method>
    		</method-permission>
    

    Este es un ejemplo del permiso de método (method-permission) en la página de código fuente del editor de descriptores de despliegue después de migrar la estructura del proyecto.

    		<method-permission>
    			<role-name>rol1</role-name>
    			<role-name>rol2</role-name>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getEJBMetaData</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean1</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>getHomeHandle</method-name>
    				<method-params>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>remove</method-name>
    				<method-params>
    					<method-param>>java.lang.Object</method-param>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Home</method-intf>
    				<method-name>remove</method-name>
    				<method-params>
    					<method-param>javax.ejb.Handle</method-param>
    				</method-params>
    			</method>
    			<method>
    				<ejb-name>TestBean2</ejb-name>
    				<method-intf>Remote</method-intf>
    				<method-name>isIdentical</method-name>
    				<method-params>
    					<method-param>javax.ejb.EJBObject</method-param>
    				</method-params>
    			</method>
    		</method-permission>
    
    Nota:
    Cuando también se selecciona la migración de beans CMP de 1.x a beans CMP de 2.x, junto con la migración de la estructura del proyecto, en el asistente de migración J2EE, los propósitos de acceso y los niveles de aislamiento se eliminan, pero todo lo demás se fusiona durante la migración. La razón de que se eliminen los propósitos de acceso y los niveles de aislamiento es que dejan de ser válidos debido a los cambios realizados en el modelo de extensiones. Con el nuevo modelo, los propósitos de acceso y los niveles de aislamiento están definidos en los propósitos de acceso, y existen propósitos de acceso a nivel de bean y propósitos de acceso a nivel de método. Siempre es preferible utilizar los propósitos de acceso a nivel de bean que los propósitos de acceso a nivel de método.

    Proyectos Web (del nivel Servlet 2.2 al nivel Servlet 2.4)

    El asistente de migración J2EE migra los artefactos de un descriptor de despliegue Web cuando se migra un proyecto Web del nivel de especificación J2EE 1.2 al nivel de especificación J2EE 1.4.

    Los artefactos de aplicaciones Web que migran son:

    Restricciones de autenticación

    En J2EE 1.4 existe un objeto Description que consta de dos atributos: language y value. El objeto Description no existía en J2EE 1.2; la descripción era un atributo de la restricción de autenticación. Por lo tanto, cuando los artefactos de un descriptor de despliegue Web migran a J2EE 1.4, el atributo value del objeto Description se obtiene del atributo description de la restricción de autenticación.

    Restricciones de seguridad

    De manera parecida, en J2EE 1.2, la descripción era un atributo de la restricción de seguridad. En J2EE 1.4, existe un nuevo objeto Description que tiene los atributos language y value. Por lo tanto, el atributo value del objeto Description se obtiene del atributo description de la restricción de seguridad.

    Aplicación Web

    La serie del atributo description del objeto ContextParam en el nivel de especificación J2EE 1.2 se ha trasladado a un objeto Description de ParamValue en J2EE 1.4.

    El objeto TagLib existente en J2EE 1.2 se ha trasladado al objeto JSPConfig en J2EE 1.4. Los objetos JSPConfig pertenecían al objeto raíz Web en J2EE 1.2.


    Cambios que presenta el asistente de migración J2EE en Rational Application Developer V6.0

    En Rational Application Developer V6.0 se han realizado cambios en el asistente de migración J2EE que afectan a la migración de todos los niveles de la especificación J2EE.

    La migración de la estructura del proyecto es opcional

    En WebSphere Studio, de la V5.1.x a la V5.1.2, la migración de la estructura del proyecto debía producirse al mismo tiempo que la migración del nivel de la especificación J2EE. La migración de la estructura del proyecto no era opcional al migrar los niveles de la especificación J2EE.

    En el asistente de migración J2EE de Rational Application Developer V6.0, la opción Migrar estructura de proyecto se puede seleccionar de manera independiente de la opción Migrar nivel de especificación J2EE de proyecto. La migración del nivel de especificación J2EE se puede realizar de forma independiente de la migración de la estructura del proyecto.

    Se necesita un servidor destino

    En Rational Application Developer V6.0, para los proyectos J2EE nuevos y existentes migrados a un nivel superior de la especificación J2EE, hay que establecer un servidor destino en el proyecto. El direccionamiento a servidor es el mecanismo predeterminado para establecer la vía de acceso de clases en un proyecto J2EE de la V6.0. En la ayuda en línea encontrará información sobre cómo establecer un servidor destino y utilizar el asistente de migración J2EE.


    Capítulo 5. Migrar a Portal Tools de Rational Application Developer V6.0

    Los proyectos de Portal Toolkit V5.0.2.2 se migrarán automáticamente a Rational Application Developer V6.0 Portal Tools migrando el área de trabajo de Portal Toolkit o cargando el proyecto de un sistema SCM (gestión de código fuente) o importando el proyecto mediante la característica Intercambio de proyectos. Si se propone migrar de las versiones anteriores de Portal Toolkit, tendrá que exportar los proyectos portlet a archivos WAR e importar los archivos WAR a Portal Tools de Rational Application Developer V6.0.

    Antes de migrar las aplicaciones portal, debe instalar la característica Portal Tools de Rational Application Developer V6.0. Consulte para ello la guía de instalación.

    Nota:
    Los proyectos portlet no son retrocompatibles.

    La migración automática solo se puede realizar para proyectos creados en Portal Toolkit V5.0.2.2 con WebSphere Studio V5.1.2. Los detalles sobre la migración trabajo están en: Capítulo 1, Migrar de WebSphere Studio V5.1, V5.1.1 o V5.1.2.

    Si el proyecto de portlet está asociado a un proyecto de aplicación de empresa, deberá establecer el servidor destino adecuado en el proyecto EAR. Puede establecer el servidor destino en la página Propiedades de servidor (Propiedades -> Servidor).

    Durante la migración de los proyectos de Portal Toolkit V5.0.2.2, tienen lugar algunos cambios adicionales:

    Si se propone migrar de las versiones anteriores de Portal Toolkit, tendrá que migrar manualmente los proyectos portlet a Portal Tools de Rational Application Developer V6.0, de la siguiente manera:

    1. Exporte el proyecto existente a un archivo WAR: En la versión anterior de Portal Toolkit, exporte cada proyecto a un archivo WAR con los archivos fuente.
      1. Pulse el proyecto con el botón derecho del ratón y seleccione Exportar.
      2. Seleccione Archivo WAR y Exportar archivos fuente y pulse Finalizar.
    2. Importe el archivo WAR del portlet:
      1. En Portal Tools para Rational Application Developer V6.0, cree un nuevo proyecto portlet vacío.
        1. Seleccione Archivo -> Nuevo -> Proyecto -> Portal -> Proyecto portlet o proyecto portlet (JSR 168).
        2. Deseleccione Crear un portlet.
        3. Pulse Mostrar avanzadas.
        4. Si está importando un portlet WebSphere Portal 4.2, seleccione 2.2 como la versión de servlet.
        5. Seleccione WebSphere Portal v5.0 como el servidor destino y pulse Finalizar.
      2. Importe el archivo WAR a este nuevo proyecto portlet vacío.
        1. Seleccione Importar.
        2. Seleccione Archivo WAR y especifique el archivo WAR que exportó en un paso anterior (Exportar el proyecto a un archivo WAR de la versión anterior).
        3. Seleccione el nuevo proyecto portlet vacío.
        4. Seleccione Sobrescribir recursos existentes sin avisar.
        5. No seleccione Suprimir proyecto al sobrescribir.
    3. Suprima el archivo TLD:

      Le recomendamos que suprima del proyecto el archivo TLD del portlet, si existe. De lo contrario, recibiría un mensaje de aviso cuando reconstruya el proyecto. Si lo deja, podría producirse un problema cuando el proyecto portlet se despliegue en WebSphere Portal y el archivo TLD del portlet sea distinto del archivo que hay en el servidor.

    4. Si está migrando un portlet WebSphere Portal 4.2, debe migrar este proyecto de portlet migrado a WebSphere Portal 5.x.

    La información sobre cómo migrar los portlets de WebSphere Portal V4.2 a V5.x se encuentra en: Migrar los portlets de WebSphere Portal V4.2 a la V5.x.

    Si desea información sobre cómo migrar los recursos Faces de un proyecto portlet, consulte: Actualizar recursos de tiempo de ejecución de Faces en un proyecto de portlet.


    Migrar los portlets de WebSphere Portal V4.2 a la V5.x

    Rational Application Developer V6.0 no soporta el desarrollo de portlets de WebSphere Portal V4.2. Debe migrar los proyectos de portlet de WebSphere Portal V4.2 a V5.x.

    La mayoría de los portlets escritos para WebSphere Portal V4.2 se ejecutarán sin cambios en WebSphere Portal V5.x. En la versión 4.2.x, algunas de las API de portlet se han marcado ahora como en desuso, pero siguen estando disponibles en WebSphere Portal V5.x.

    Nota:
    Los proyectos de aplicación portlet migrados no son retrocompatibles.

    Para migrar las aplicaciones portlet de WebSphere Portal V4.2 a la V5.x, siga estos pasos:

    1. Migre los proyectos portlet de Portal V4.2 a proyectos portlet de Portal V5.x:
      1. Con el botón derecho del ratón, pulse el proyecto de la aplicación portlet que desea migrar.
      2. Seleccione Propiedades -> API de Portlet para abrir la página de las API de portlet.
      3. Seleccione WebSphere Portal Versión 5.x en la lista desplegable en la que figuran los niveles de las API de portlet.
      4. Pulse Aceptar, y se producirán automáticamente los siguientes cambios:
        • Se elimina el archivo del descriptor de biblioteca de códigos (TLD) de la API de portlet, si existe.
        • El nivel Web pasa de 2.2 a 2.3.
        • Se eliminan las entradas de vía de acceso de clases específicas del portlet, porque el contenedor de JRE de WebSphere Portal y el contenedor del destino de tiempo de ejecución de WebSphere Portal las añadirán dinámicamente.
    2. Si el proyecto portlet está asociado a un proyecto de aplicación de empresa, le recomendamos que migre el nivel J2EE del proyecto EAR a J2EE 1.3. Las aplicaciones portlet diseñadas para WebSphere Portal V5.x deben estar en conformidad con las especificaciones J2EE de nivel 1.3.
      Nota:
      Antes de migrar el proyecto de aplicación de empresa a J2EE 1.3, lea: Capítulo 4, Migrar proyectos J2EE. En la ayuda en línea encontrará información sobre cómo utilizar el asistente de migración J2EE.
      1. Si el proyecto portlet migrado tan solo está asociado al proyecto de aplicación de empresa, haga como se indica a continuación:
        1. Cierre todos los editores del entorno de trabajo.
        2. Con el botón derecho del ratón, pulse el proyecto de aplicación de empresa al que está asociado el proyecto portlet migrado.
        3. Seleccione Migrar -> Asistente de migración J2EE, y pulse Siguiente.
        4. Seleccione J2EE Versión 1.3 y WebSphere Portal como servidor destino.
        5. Pulse Finalizar.
      2. Si hay otros proyectos portlet asociados al proyecto de aplicación de empresa, debe eliminar el proyecto portlet migrado y añadirlo a otro proyecto de aplicación de empresa.
        1. Elimine del proyecto de aplicación de empresa el módulo del proyecto portlet migrado.
          1. Expanda el proyecto de aplicación de empresa y seleccione el descriptor de despliegue.
          2. Seleccione Abrir con -> Editor de descriptores de despliegue.
          3. Seleccione la pestaña Módulo. En el editor, en la página Módulo, seleccione el archivo WAR del proyecto portlet migrado.
          4. Pulse Eliminar.
          5. Seleccione Archivo -> Guardar para guardar los cambios.
        2. Cree un nuevo proyecto de aplicación de empresa y añádale el proyecto portlet.
          1. Seleccione Archivo -> Nuevo -> Proyecto.
          2. Marque el recuadro de selección Mostrar todos los asistentes.
          3. Expanda J2EE y seleccione Proyecto de aplicación de empresa.
          4. Cumplimente el campo Nombre del proyecto, seleccione J2EE Versión 1.3 y WebSphere Portal como servidor destino, y pulse Siguiente.
          5. En la página Proyectos de módulo EAR, seleccione el proyecto portlet migrado y pulse Finalizar.

    Ahora, el proyecto portlet ya habrá migrado a WebSphere Portal V5.x.


    Actualizar recursos de tiempo de ejecución de Faces en un proyecto de portlet

    Los recursos de tiempo de ejecución de JavaServer Faces enviados originalmente con WebSphere Studio Application Developer V5.1.2 se han actualizado para Rational Application Developer V6.0.1. Si desea seguir desarrollando proyectos de portlet creados con Portal Toolkit 5.0.2.2 para esta versión anterior del producto, es recomendable que actualice los recursos de tiempo de ejecución Faces a los últimos niveles.

    En Rational Application Developer V6.0.1, las actualizaciones de los recursos de tiempo de ejecución de Faces se producen automáticamente cuando se importa un proyecto de portlet o se abre un área de trabajo que contiene recursos no actualizados. Después de importar un proyecto de portlet creado con Portal Toolkit 5.0.2.2 para WebSphere Studio Application Developer V5.1.x a Rational Application Developer V6.0.1, se le solicitará que actualice los recursos de tiempo de ejecución de Faces a los últimos niveles.

    Actualizar automáticamente recursos de tiempo de ejecución

    Para actualizar automáticamente los recursos de tiempo de ejecución de Faces para un proyecto de portlet:

    1. Importe un proyecto de portlet con contenido Faces de WebSphere Studio Application Developer V5.1.x. Se abre la ventana Migración de proyectos.
      Nota:
      Si la ventana Migración de proyectos no se abre, el valor de preferencia de construcción automática esté probablemente inhabilitado. En el Explorador de proyecto, pulse con el botón derecho del ratón sobre el proyecto de portlet y seleccione Construir -> Proyecto; el proceso de reconstrucción de un proyecto abre la ventana Migración de proyectos.
    2. Si tiene otros proyectos de portlet con contenido de Faces en el área de trabajo, marque Aplicar esta opción a cualesquiera otros proyectos que necesiten actualizarse y se actualizarán todos los proyectos de portlet.
    3. Pulse una de las opciones siguientes:
    4. Para actualizar los recursos de tiempo de ejecución Faces específicos del portlet, jsf-portlet.jar y jsf-wp.jar, debe seguir los pasos de actualización manual que se indican a continuación.
    Nota:
    Si ha creado JSP Faces que contenían componentes de cliente Faces, debe actualizar por separado los recursos de tiempo de ejecución de componentes de cliente Faces a los últimos niveles. Consulte Actualizar recursos de tiempo de ejecución de cliente Faces en un proyecto Web.

    Actualizar manualmente recursos de tiempo de ejecución

    Para actualizar manualmente los recursos de tiempo de ejecución de Faces para un proyecto de portlet:

    1. Importe el proyecto portlet existente con el contenido Faces a un área de trabajo de Rational Application Developer V6.0.1.
    2. Cree un nuevo proyecto portlet que se llame JSFP601, teniendo seleccionada la opción Portlet Faces en la segunda página. Este proyecto tan solo lo utilizará como origen de los recursos de tiempo de ejecución más recientes; puede suprimirse una vez realizada la actualización.
    3. En el explorador de proyectos, pulse el proyecto JSFP601 con el botón derecho del ratón y seleccione Propiedades en el menú.
    4. Pulse Características de proyecto Web, seleccione Añadir infraestructura de cliente Faces para proyecto de portlet y pulse Aceptar.
    5. Para cada proyecto Faces existente que desee actualizar, haga lo siguiente:
      1. Expanda un proyecto existente en el Explorador de proyectos para ver los archivos que hay en la carpeta WebContent/WEB-INF/lib/. En este directorio, localice cada uno de los siguientes archivos JAR y suprímalos:
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • jsf-portlet.jar
        • odc-jsf.jar
      2. Localice el archivo WebContent/WEB-INF/faces-config.xml. Añada los siguientes elementos a este archivo de configuración, si todavía no están presentes:
        	<lifecycle>
        		<phase-listener>com.ibm.faces.webapp.ValueResourcePhaseListener</phase-listener>
        	</lifecycle>
        	
        	<application>
        		<variable-resolver>com.ibm.faces.databind.SelectItemsVarResolver</variable-resolver>
        		<variable-resolver>com.ibm.faces.application.WPPortletVariableResolver</variable-resolver>
        		<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
        	</application>
        
        Nota:
        Si el proyecto portlet utiliza la API JSR 168, especifique com.ibm.faces.application.PortletVariableResolver, en lugar de com.ibm.faces.application.WPPortletVariableResolver.
      3. Por cada uno de los archivos JAR que suprimió, copie el archivo JAR que tenga el mismo nombre en el directorio WebContent/WEB-INF/lib del proyecto JSFP601 y péguelo en el proyecto original en la misma ubicación. En algunas configuraciones no hará falta que todos estos archivos JAR estén presentes en el proyecto; no copie un archivo JAR determinado si no estaba en el proyecto original.
        • Si el proyecto portlet utiliza la API de portlet de IBM o un componente de enlace personal, copie el archivo jsf-wp.jar en el proyecto original.
        • Si copia el archivo odc-jsf.jar, copie asimismo el archivo odc-jsf-portlet.jar.
      4. Abra el descriptor de despliegue web.xml del proyecto original y añada las siguientes líneas de código a la configuración:
        	<context-param>
        		<param-name>com.ibm.ws.jsf.JSP_UPDATE_CHECK</param-name>
        		<param-value>true</param-value>
        	</context-param>
        	<context-param>
        		<param-name>com.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP</param-name>
        		<param-value>true</param-value>
        	</context-param>
        
    6. Suprima el proyecto de portlet JSFP601.

    Capítulo 6. Cambios realizados en los entornos de prueba de WebSphere

    En Rational Application Developer V6.0, los entornos de prueba de WebSphere Application Server que venían con el producto han sufrido cambios que los diferencian de los que venían con las ediciones anteriores de WebSphere Studio Application Developer.

    A continuación se proporciona un resumen de los cambios realizados en los entornos de prueba de WebSphere Application Server en Rational Application Developer V6.0:

    La siguiente tabla muestra los niveles de los entornos de prueba de WebSphere Application Server que venían con las distintas versiones de WebSphere Studio Application Developer y Rational Application Developer.

    Tabla 2. Entornos de prueba de WebSphere Application Server en WebSphere Studio Application Developer y Rational Application Developer


    WebSphere Application Server V4.x AE WebSphere Application Server V5.x Base WebSphere Application Server Express 5.x WebSphere Application Server V5.x Portal WebSphere Application Server V6.0
    WebSphere Studio Application Developer V5.1 V4.0.6 V5.0.2 V5.0.2 No aplicable No aplicable
    WebSphere Studio Application Developer V5.1.1 V4.0.7 + PQ78374 V5.0.2 + PQ78374 + PQ78419, V5.1 V5.0.2 y V5.1 No aplicable No aplicable
    WebSphere Studio Application Developer V5.1.2 V4.0.7 + PQ78374 V5.0.2 + PQ78374 + PQ78419, V5.1.0.3 V5.0.2 y V5.1.0.3 V5.0.2.3 Base + WebSphere Portal V5.0.2.1 No aplicable
    Rational Application Developer V6.0 No aplicable V5.0.x, V5.1.1 V5.0.2 y V5.1.1 V5.0.2.6 Base + WebSphere Portal V5.0.2.2, V5.1.1 Base + WebSphere Portal 5.1 V6.0

    Copyright y avisos