Guía para la migración de IBM Rational Web 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 Web Developer V6.0

    Capítulo 3. 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 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
  • Proyectos Web (del nivel Servlet 2.2 al nivel Servlet 2.4)
  • Cambios que presenta el asistente de migración J2EE en Rational Web Developer V6.0
  • Capítulo 4. 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 Site Developer V5.1.x a Rational Web 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 Web 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 Web 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 Web 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 Web 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 Web 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 Web Developer V6.0. All EGL projects are safely migrated without this perspective in Rational Web 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 Web 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 Web 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 Web Developer V6.0. Si ha creado conexiones JDBC mediante el controlador JDBC de DB2 Net, no podrá volver a conectar en Rational Web 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 Site 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 Site Developer V5.1.x, deberá obtener los correspondientes conectores de la V6.0 y volver a instalarlos.
    9. Si utiliza características que requieran Agent Controller, actualícelo, instalando la versión que viene con Rational Web Developer. Encontrará los detalles en la guía de instalación.
    10. 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 Web 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 Site 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 Web 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 Web Developer V6.0, se crea automáticamente un archivo .compatibility en el directorio del proyecto. El producto Rational Web 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 Site Developer V5.1.x en: Inhabilitar la compatibilidad con WebSphere Studio V5.1.x.

    Consideraciones sobre Eclipse

    Esta versión de Rational Web 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 Web 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 Web 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 Web 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 Site 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 Web 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 Web Developer V6.0 y WebSphere Studio Site 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 Web Developer V6.0, se perderá la compatibilidad de los proyectos J2EE y habrá que restablecerla.

    Inhabilitar la compatibilidad con WebSphere Studio V5.1.x

    La compatibilidad con WebSphere Studio Site Developer V5.1.x se puede eliminar totalmente de un proyecto de aplicación de empresa creado en Rational Web 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 Site 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 Site 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 Site Developer V5.1.x se han actualizado para Rational Web 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 Web 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 Site Developer V5.1.x a Rational Web 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 Site 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 Web 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 Site Developer V5.1.x se han actualizado para Rational Web 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 Web 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 Site Developer V5.1.x a Rational Web 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 Site 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 Web 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 Web 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 Web 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 Web 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 Site Developer se abre en Rational Web 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 Web Developer V6.0. Si migra un área de trabajo de WebSphere Studio Site 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 Web 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 Web 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 Web Developer V6.0

    Los recursos de tiempo de ejecución de Faces y cliente Faces enviados originalmente en Rational Web Developer V6.0 se han actualizado para Rational Web 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 Web 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 Web Developer V6.0.x a Rational Web 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 Web 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. Migrar proyectos J2EE

    El asistente de migración J2EE se ha actualizado en Rational Web 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 Web 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 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 3, Migrar proyectos J2EE.

    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 Web Developer V6.0

    En Rational Web 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 Web 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 Web 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 4. Cambios realizados en los entornos de prueba de WebSphere

    En Rational Web 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 Site Developer.

    A continuación se proporciona un resumen de los cambios realizados en los entornos de prueba de WebSphere Application Server en Rational Web 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 Site Developer y Rational Web Developer.

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


    WebSphere Application Server V4.x AE WebSphere Application Server V5.x Base WebSphere Application Server Express V5.x WebSphere Application Server V6.0
    WebSphere Studio Site Developer V5.1 V4.0.6 V5.0.2 V5.0.2 No aplicable
    WebSphere Studio Site Developer V5.1.1 V4.0.7 + PQ78374 V5.0.2 + PQ78374 + PQ78419, V5.1 V5.0.2 y V5.1 No aplicable
    WebSphere Studio Site 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 No aplicable
    Rational Web Developer V6.0 No aplicable V5.0.x, V5.1.1 V5.0.2 y V5.1.1 V6.0

    Copyright y avisos