Guía para la migración de IBM Rational Web Developer para Windows y Linux, Versión 6.0
Capítulo 1. Migrar de WebSphere Studio V5.1, V5.1.1 o V5.1.2
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
Capítulo 4. Cambios realizados en los entornos de prueba de WebSphere
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:
- 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.
- Haga copia de seguridad del área de trabajo de WebSphere Studio
V5.1.x.
- 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.
- 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).
- 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:
- 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:
- Cierre la perspectiva, seleccionando Ventana ->
Cerrar perspectiva.
- 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:
- Cierre la perspectiva Web EGL.
- 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.
- Seleccione Ventana -> Abrir perspectiva y
elija la perspectiva Web.
- 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.
- 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:
- Para cada proyecto V5.1.x migrado a V6.0, el programa
de migración añade automáticamente un archivo .compatibility a
la carpeta del proyecto en V6.0. Este archivo sirve para
proporcionar retrocompatibilidad con WebSphere Studio
V5.1.x. No debe editar ni suprimir este archivo.
Hallará más información en el apartado sobre compatibilidad con WebSphere Studio
V5.1.x.
Importante:
- Si hay configuraciones de lanzamiento de depuración asociadas al
área de trabajo que se propone migrar, se fijará en que algunas
configuraciones de lanzamiento no migran automáticamente. Para
obtener información sobre cómo restaurar las configuraciones de
lanzamiento de un área de trabajo migrada, consulte: Cambios que presenta el depurador en la V6.0.
- Si ha utilizado el depurador XSLT o el depurador EGL en los proyectos del
área de trabajo migrada, tendrá que cambiar el entorno de tiempo de
ejecución Java (JRE) que se instala con Rational Web Developer
V6.0. Los detalles sobre cómo hacer este cambio están
en: Cambios que presenta el depurador en la V6.0.
- Si tiene programas desarrollados con el lenguaje de generación para
empresas (EGL) migrados a V6.0, debe tener en cuenta que hay nuevas
palabras reservadas de EGL en la Versión 6.0. Si utiliza esas
palabras como nombres de variables o de componentes, tendrá que
cambiarlas. Consulte: Palabras reservadas del EGL en V6.0.
- 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.
- 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.
- 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.
- 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.
- 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.
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:
- Modificar los metadatos de compatibilidad que se añaden al archivo
.project y al archivo .compatiblity creados por la herramienta
de migración.
- Suprimir el archivo
.compatibility de esos proyectos.
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 con los releases anteriores
- Actualizar el área de trabajo de un release anterior
- Interoperatividad con los releases anteriores
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:
- Abra el archivo .classpath de cada proyecto J2EE que
tenga ese archivo.
- Suprima las siguientes entradas de vía de acceso de clases
(classpathentry) del archivo
.classpath y, después, guarde el archivo y ciérrelo.
-
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/
org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere v5.1 JRE"/>
-
<classpathentry kind="con"
path="com.ibm.wtp.server.java.core.container/
com.ibm.etools.websphere.runtime.core.runtimeTarget.v51/was.base.v51"/>
- 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".
- Pulse el proyecto con el botón derecho del ratón y seleccione
Propiedades -> J2EE.
- 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.
- 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.
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:
- 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.
- 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.
- Pulse Sí 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.
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:
- 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.
- 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.
- Pulse una de las opciones siguientes:
- Sí para realizar la actualización
automáticamente.
- Más tarde para diferir la actualización. Para
actualizar automáticamente los recursos de tiempo de ejecución
después de seleccionar Más tarde, debe cerrar y reabrir el
proyecto Web o reiniciar el entorno de trabajo antes de reconstruir el
proyecto Web. Si ha inhabilitado las construcciones automáticas,
pulse con el botón derecho del ratón sobre el proyecto Web y seleccione
Construir proyecto.
- Nunca para mantener los recursos de tiempo de ejecución en
un nivel anterior. Si elige Nunca y se queda
intencionadamente con los recursos de tiempo de ejecución en un nivel
anterior, no se le volverá a solicitar que los actualice. Más
adelante tendrá que actualizar los recursos de tiempo de ejecución
manualmente si los necesita.
- 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:
- Importe el proyecto Web existente con el contenido Faces a un área de
trabajo de Rational Web Developer V6.0.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.
- En el explorador de proyectos, pulse el proyecto JSF601 con el
botón derecho del ratón y seleccione Propiedades en el
menú.
- Pulse Características de proyecto Web y seleccione
Añadir componentes de base Faces y Añadir
infraestructura de cliente Faces y pulse Aceptar.
- Si está trabajando con EGL, cree un archivo de página JSF
de la forma siguiente:
- Pulse el botón derecho del ratón sobre la carpeta WebContent del
proyecto Web EGL nuevo.
- Seleccione Nuevo -> Otros ->
Archivo JSP Faces.
Los archivos eglintdebug.jar y
eglintdebugsupport.jar se añaden al proyecto.
- Para cada proyecto Faces existente que desee actualizar, haga lo
siguiente:
- 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
- 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>
- 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.
- 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>
- Si el proyecto original utiliza Objetos de datos de WebSphere (WDO) para
cualquier acceso de datos, siga estos pasos adicionales:
- En el proyecto original, pulse Archivo ->
Nuevo -> Archivo JSP Faces para crear un archivo
JSP Faces temporal nuevo.
- Arrastre un componente de lista de registro relacional de la bandeja Datos
de la paleta a la página.
- 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.
- Suprima el archivo JSP temporal.
- 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.
- Suprima el proyecto Web JSF601.
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:
- 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.
- 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.
- Pulse una de las opciones siguientes:
- Sí para realizar la actualización
automáticamente.
- Más tarde para diferir la actualización. Para
actualizar automáticamente los recursos de tiempo de ejecución
después de seleccionar Más tarde, debe cerrar y reabrir el
proyecto Web o reiniciar el entorno de trabajo antes de reconstruir el
proyecto Web. Si ha inhabilitado las construcciones automáticas,
pulse con el botón derecho del ratón sobre el proyecto Web y seleccione
Construir proyecto.
- Nunca para mantener los recursos de tiempo de ejecución en
un nivel anterior. Si elige Nunca y se queda
intencionadamente con los recursos de tiempo de ejecución en un nivel
anterior, no se le volverá a solicitar que los actualice. Más
adelante tendrá que actualizar los recursos de tiempo de ejecución
manualmente si los necesita.
- 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.
- En la carpeta Recursos Java -> JavaSource del
proyecto Web, abra el archivo OdysseyBrowserFramework.properties y
suprima las entradas para EMAP_FILES y
ECORE_FILES.
- Para cada objeto de datos de la vista Datos de cliente:
- Pulse con el botón derecho del ratón y seleccione
Configurar.
- 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:
- 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.
- 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:
- Las clases de mediador de datos de cliente que ya se hayan generado no se
compilarán más. Deben regenerarse un JSP a la vez.
- Abra el archivo OdysseyBrowserFramework.properties que se encuentra
en la carpeta origen Java raíz. Guarde el contenido para utilizarlo
posteriormente.
- En el archivo OdysseyBrowserFramework.properties, para cada JSP del
proyecto Web que contenga datos de cliente Faces, busque las entradas
<client-data-name>.ecore y <client-data-name>.emap
correspondientes a las propiedades EMAP_FILES y ECORE_FILES.
- Guarde solo las entradas coincidentes para los datos de cliente en el JSP
y suprima el resto de entradas.
Por ejemplo, si la página actual tiene datos de cliente llamados ACCOUNT
y el archivo de propiedades tenía una entrada como esta:
EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap com\\ibm\\dynwdo4jsmediators/orders.emap
debe suprimir com\\ibm\\dynwdo4jsmediators/orders.emap de
la entrada. La entrada tendrá ahora el aspecto siguiente:
EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap
- Guarde el archivo de propiedades.
- Seleccione un objeto de datos de cliente en un JSP, pulse con el botón
derecho del ratón y seleccione Configurar.
- En la pestaña Avanzadas, pulse Regenerar
todo. Esto regenerará todos los artefactos necesarios para
todos los datos de cliente en el JSP actual.
- Repita los pasos 2-6 para cada JSP que contenga datos de cliente en el
proyecto Web.
- Después de regenerar las clases de mediador de datos de cliente,
quedarán algunas clases de mediador que no compilarán. Se trata
de mediadores para elementos de esquema que ya no se utilizan en Objetos de
datos de servicio (SDO) en V6.x y que siguen el convenio de
denominación *_DataGraphSchema_wdo4js_*.java y
*_RootDataObject_wdo4js_*.java. Suprima estas clases de mediador
del proyecto Web para evitar estos errores de compilación.
- Una vez que la actualización se haya realizado satisfactoriamente,
restaure el contenido original del archivo
OdysseyBrowserFramework.properties.
- Los componentes de cliente Faces de vista de árbol enlazados a los WDO
no pueden ejecutarse en el servidor después de cambiar el servidor destino
del proyecto a WebSphere Application Server V6.0. La solución
consiste en modificar la vista del fuente del JSP para cambiar todos los
códigos de className para que utilicen la clase DataObject de SDO en lugar
de la clase DataObject de WDO. Por ejemplo, para un WDO llamado
account:
- Para el objeto raíz, cambie el código className de
className="com.ibm.etools.wdo.DataObject(DynWDO`account`RootDataObject)"
a
className="commonj.sdo.DataObject(DynWDO`account`DataGraphRoot)".
- Para todos los nodos hijo, cambie el código className de
className="com.ibm.etools.wdo.DataObject(DynWDO`account`ACCOUNT)"
a
className="commonj.sdo.DataObject(DynWDO`account`ACCOUNT)",
donde ACCOUNT es el nombre del nodo de datos.
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:
- Genere los manejadores y procesadores Diff nuevos en cada objeto de datos
de cliente en el proyecto Web.
- Seleccione el Objeto de datos de cliente, pulse con el botón derecho
del ratón y seleccione Configurar.
- En la pestaña Avanzadas, pulse Regenerar
todo.
- 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";
- 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.
- La interfaz DiffHandler ha cambiado de la manera siguiente:
- El método handle ahora lanza Exception además de
DiffException.
- El método find nuevo lo utiliza la infraestructura para buscar
objetos.
- El método getId nuevo se utiliza para depurar y permite que la
infraestructura imprima el valor de un objeto.
Los métodos find y getId los utilizan internamente los DiffHandler
generados. Para los DiffHandler personalizados puede implementar
métodos vacíos para que se ajusten a la interfaz. La
infraestructura llamará ahora a estos métodos.
La interfaz DiffHandler es ahora:
public interface DiffHandler
{
public void handle(DiffInfo Diff) throws DiffException, Exception;
public Object find (DiffInfo Diff) throws DiffException, Exception;
public String getId (DiffInfo Diff, boolean Original);
}
- La clase DiffInfo ha cambiado de la forma siguiente:
- El método ArrayList getAncestors() se ha sustituido por el método
DiffInfo getParent() que proporciona una forma más fácil de acceder a la
información para cada objeto en el árbol de ancestros de forma
recursiva.
- Los métodos getCurrent() y getOriginal() ahora devuelven un objeto
DataObject en lugar de un objeto EObject. No es obligatorio que cambie
el código para utilizar el objeto DataObject. Sin embargo, la
interfaz DataObject es más fácil y más intuitiva de utilizar que
EObject. Puede convertir temporalmente un objeto DataObject en un
objeto EObject fácilmente para el código existente.
- Se ha añadido un método getPropertyName() de String nuevo para
identificar el nombre de propiedad al que se aplica este objeto. Esto
es importante si, por ejemplo, una clase dada tiene dos propiedades del mismo
tipo. Anteriormente en la clase DiffInfo el código no hubiera podido
diferenciar entre ambas propiedades.
La clase DiffInfo es ahora:
public class DiffInfo
{
public char getCrud()
public DataObject getCurrent()
public String getEClassName()
public DataObject getOriginal()
public String getPropertyName()
public DiffInfo getParent()
}
- Nota:
- La clase DiffInfo ya no está soportada para uso público ya que los
procesadores y manejadores Diff se generan automáticamente. Mantener
los manejadores antiguos solo es una solución temporal y se aconseja
encarecidamente que se utilicen los manejadores automatizados.
Cambios en los componentes de cliente Faces en
V6.0:
- Soporte para WebSphere Application Server V6.0.
- Soporte para Objetos de datos de servicio (SDO) en WebSphere Application
Server V6.0.
- Los datos EGL se soportan ahora como datos de cliente.
- Los procesadores Diff y los manejadores se generan
automáticamente.
- Hay eventos nuevos para los componentes siguientes:
- TabbedPanel: onInitialPageShow
- Tree: onNodeExpand, onNodeCollapse, onExpand, onCollapse
- DataGrid: onPage, onSort, onFilter
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:
- Abra el proyecto Web de Struts en el Explorador de proyectos.
- 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.
- Pulse la pestaña Fuente para abrir la página
Fuente.
- 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>
.
- 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:
- Cargue los proyectos de Struts 1.1 Beta en un entorno de trabajo de
Rational Web Developer V6.0.
- 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.
- Para cada proyecto de Struts 1.1 que desee convertir a Struts
1.1, haga lo siguiente:
- Suprima los archivos JAR siguientes del directorio Web Content/WEB-INF/lib
del proyecto:
- commons-*.jar.
- struts.jar.
- 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.
- Suprima los archivos TLD (Descriptor de biblioteca de códigos) del
directorio Web Content/WEB-INF del proyecto: struts-*.tld.
- 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:
- Cargue los proyectos de Struts 1.0.2 en un área de
trabajo de Rational Web Developer V6.0.
- 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.
- Para cada proyecto de Struts 1.0.2 que desee convertir a
Struts 1.1, haga lo siguiente:
- Suprima el archivo struts.jar del directorio Web
Content/WEB-INF/lib del proyecto.
- 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.
- Suprima los archivos TLD (Descriptor de biblioteca de códigos) del
directorio Web Content/WEB-INF del proyecto: struts-*.tld.
- Copie los archivos TLD siguientes del directorio
Struts11/WebContent/WEB-INF al directorio Web Content/WEB-INF del
proyecto: struts-*.tld.
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:
- Depurar en servidor: las configuraciones de lanzamiento
que se crearon anteriormente por medio de la acción Depurar en servidor no
migrarán a la V6.0. Si desea lanzar una aplicación para
que se depure en un servidor en la V6.0, vuelva a seleccionar la
aplicación y elija la acción Depurar en servidor.
Así se creará una nueva configuración de lanzamiento para la
aplicación.
- Conexión de servidor: las configuraciones de
lanzamiento de depuración de WebSphere Application Server que se crearon
anteriormente para una conexión de servidor no migrarán a la
V6.0. La configuración de lanzamiento de depuración de
WebSphere Application Server ha dejado de existir. Con el fin de
realizar una conexión de servidor para depurarla en la V6.0, utilice
la acción Depurar en servidor y cree una conexión de servidor
de WebSphere V5 para 5.x o una conexión de servidor de WebSphere
V6.0 para 6.0.
- Depurador SQLJ: la configuración de lanzamiento de
depuración SQLJ ha dejado de existir, por lo que las configuraciones de
lanzamiento SQLJ que se hayan creado anteriormente no migrarán a la
V6.0. Con el fin de lanzar programas SQLJ para depuración en
la V6.0, utilice la configuración de lanzamiento de aplicaciones
Java.
- Depurador de procedimientos almacenados: las
configuraciones de lanzamiento del depurador de procedimientos almacenados que
se hayan creado con anterioridad migrarán a Rational Web Developer
V6.0 y estarán disponibles para utilización en el diálogo de
configuraciones de lanzamiento de la acción Depurar.
Después de migrar, si utiliza la acción Depurar del menú
emergente de la vista Definición de datos, se creará
automáticamente una nueva configuración de lanzamiento.
- Nota:
- Si migra un área de trabajo que contenga un procedimiento almacenado y
luego reconstruye el procedimiento almacenado para la depuración, las
configuraciones de lanzamiento migradas que estén asociadas al
procedimiento almacenado no funcionarán.
- Depurador EGL: después de migrar un área de
trabajo, habrá que realizar los siguientes pasos para las configuraciones
de lanzamiento existentes del depurador EGL:
- Modifique el entorno de tiempo de ejecución Java (JRE) para que
señale hacia la ubicación correcta. Después de migrar un
área de trabajo, el correspondiente JRE instalado señalará hacia el
JRE de la versión anterior de WebSphere Studio Site Developer. Para
cambiar esta peculiaridad, haga que señale hacia la nueva ubicación del
JRE, de la siguiente manera:
- Seleccione Ventana -> Preferencias en el
menú del entorno de trabajo.
- En el diálogo Preferencias obtenido, expanda el nodo Java y
después seleccione JRE instalados.
- En la parte derecha, establezca el JRE instalado para que señale hacia
el JRE que se ha instalado con la versión actual de este producto.
La ubicación del JRE es el subdirectorio \eclipse\jre del directorio de
instalación de Rational Web Developer V6.0.
- En la configuración de lanzamiento, seleccione la pestaña
Fuente antes del lanzamiento (si no lo hace así, recibirá un
mensaje de error que indica que no se ha encontrado el fuente). Si
había añadido ubicaciones del fuente a la configuración de
lanzamiento en el área de trabajo de la V5.1.x, tendrá que
añadir manualmente esas ubicaciones de nuevo a la configuración de
lanzamiento migrada.
- Depurador de lenguaje compilado: después de migrar un
área de trabajo, habrá que realizar los siguientes pasos para las
configuraciones de lanzamiento existentes del depurador de lenguaje
compilado:
- Si había establecido variables de entorno en la pestaña Entorno
del sistema de la configuración de lanzamiento de la
aplicación compilada, tendrá que volver a añadirlas
manualmente a la configuración de lanzamiento migrada.
- Si había añadido ubicaciones del fuente a las configuraciones de
lanzamiento de Aplicación compilada o Conectar a un proceso
en ejecución, tendrá que volver a añadirlas manualmente a la
configuración de lanzamiento migrada.
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:
- Cambie el JRE de toda el área de trabajo de manera que señale hacia
la nueva ubicación del JRE , siguiendo estos pasos:
- Seleccione Ventana -> Preferencias en el
menú del entorno de trabajo.
- En la ventana Preferencias, expanda el nodo Java y después
seleccione JRE instalados.
- En la parte derecha, establezca el JRE instalado para que señale hacia
el JRE que se ha instalado con la versión actual de este producto.
La ubicación del JRE es el subdirectorio \eclipse\jre del directorio de
instalación de Rational Web Developer V6.0.
- Si se propone lanzar la sesión de depuración por medio del
diálogo de configuraciones de lanzamiento de Depurar, puede
cambiar el JRE de la configuración de lanzamiento haciendo que señale
hacia la nueva ubicación del JRE. Para ello, abra la
configuración de lanzamiento en el diálogo de configuraciones de
lanzamiento de Depurar. Seleccione la pestaña
JRE y especifique la nueva ubicación del JRE en el campo
JRE alternativo.
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:
- Puede modificar el servidor destino utilizando el diálogo de
propiedades del proyecto. En la vista Explorador de proyectos, pulse el
proyecto con el botón derecho del ratón y seleccione
Propiedades -> Servidor -> Tiempo de
ejecución destino.
- Durante la migración de J2EE mediante el asistente de migración
J2EE, puede cambiar el destino de la aplicación para que utilice otro
servidor.
- Nota:
- Solo se puede migrar a un nivel de especificación J2EE más alto.
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
- El código que se haya escrito para las interfaces de programación de
aplicaciones (API) públicas de los beans de acceso WDO se podrá utilizar
en la V6.0 (aunque las clases de implementación han cambiado para
tomar como destino el código de tiempo de ejecución SDO).
- El nuevo código que se genere para WebSphere Application Server
V6.0 no utilizará los beans de acceso WDO, sino que en su lugar se
generará código para las API puramente SDO.
- El código que se haya generado para un proyecto mientras se tomaba la
V6.0 como destino no funcionará en un servidor de la V5.1, ni
siquiera si se migra de nuevo volviendo a tomar como destino el
servidor.
- El código escrito para V5.1 puede migrar hacia delante y hacia
atrás tomando como destino un servidor de la V5.1.
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:
- 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;
- 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:
- Los archivos Java de archivado (JAR) wdo_web.jar y
wdo_jdbc_access.jar se eliminan del proyecto.
- Los siguientes archivos JAR se eliminan de la vía de acceso de clases
del proyecto:
- emf-runtime.jar
- emf-event.jar
- wdo-interface.jar
- wdo.jar
- jdbcmediator.jar
- wdo.xmlmediator.jar
- Se añaden los archivos sdo_web.jar y sdo_access_beans.jar
al proyecto (los archivos JAR de tiempo de ejecución SDO se añaden
automáticamente a la vía de acceso de clases de todo proyecto de la
V6.0).
- Los archivos JAR de la biblioteca de códigos JavaServer Pages
estándar (JSTL) 1.0 se eliminan del proyecto. (Los archivos
JAR de JSTL 1.1/JSP 2.0 se añaden automáticamente a la
vía de acceso de clases de todo proyecto de la V6.0).
- En los archivos fuente Java, se añaden las siguientes sentencias de
importación:
- com.ibm.websphere.wdo.access.connections.ConnectionManager
pasa a ser
com.ibm.websphere.sdo.access.connections.ConnectionManager.
- com.ibm.websphere.wdo.mediator.rdb.ConnectionWrapper
pasa a ser
com.ibm.websphere.sdo.mediator.jdbc.ConnectionWrapper.
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:
- Los archivos JAR sdo_web.jar y sdo_access_beans.jar se
eliminan del proyecto.
- Se añaden los archivos JAR wdo_web.jar y
wdo_jdbc_access.jar al proyecto.
- A la vía de acceso de clases del proyecto, se añaden los siguientes
archivos JAR:
- emf-runtime.jar
- emf-event.jar
- wdo-interface.jar
- wdo.jar
- jdbcmediator.jar
- wdo.xmlmediator.jar
- Se añaden archivos JAR de JSTL 1.0 al proyecto. (Los
archivos JAR de JSTL 1.1/JSP 2.0 se eliminan de ka vía de
acceso de clases del proyecto).
- En los archivos fuente Java, se añaden las siguientes sentencias de
importación:
- com.ibm.websphere.sdo.access.connections.ConnectionManager
pasa a ser
com.ibm.websphere.wdo.access.connections.ConnectionManager.
- com.ibm.websphere.sdo.mediator.jdbc.ConnectionWrapper
pasa a ser
com.ibm.websphere.wdo.mediator.rdb.ConnectionWrapper.
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
|
En Rational Web Developer, hay nuevas palabras reservadas en el lenguaje de
generación para empresas (EGL).
Las nuevas palabras reservadas son las siguientes:
- as
- isa
- like
- matches
- money
- openUI
- ref
- self
- string
- this
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.
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:
- 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.
- 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.
- Pulse una de las opciones siguientes:
- Sí para realizar la actualización
automáticamente.
- Más tarde para diferir la actualización. Para
actualizar automáticamente los recursos de tiempo de ejecución
después de seleccionar Más tarde, debe cerrar y reabrir el
proyecto Web o reiniciar el entorno de trabajo antes de reconstruir el
proyecto Web. Si ha inhabilitado las construcciones automáticas,
pulse con el botón derecho del ratón sobre el proyecto Web y seleccione
Construir proyecto.
- Nunca para mantener los recursos de tiempo de ejecución en
un nivel anterior. Si elige Nunca y se queda
intencionadamente con los recursos de tiempo de ejecución en un nivel
anterior, no se le volverá a solicitar que los actualice. Más
adelante tendrá que actualizar los recursos de tiempo de ejecución
manualmente si los necesita.
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:
- 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.
- En el explorador de proyectos, pulse el proyecto JSF601 con el
botón derecho del ratón y seleccione Propiedades en el
menú.
- Pulse Características de proyecto Web y seleccione
Añadir componentes de base Faces y Añadir
infraestructura de cliente Faces y pulse Aceptar.
- Si está trabajando con EGL, cree un archivo de página JSF
de la forma siguiente:
- Pulse el botón derecho del ratón sobre la carpeta WebContent del
proyecto Web EGL nuevo.
- Seleccione Nuevo -> Otros ->
Archivo JSP Faces.
Los archivos eglintdebug.jar y
eglintdebugsupport.jar se añaden al proyecto.
- Para cada proyecto Faces existente que desee actualizar, haga lo
siguiente:
- 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
- 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.
- 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.
- Suprima el proyecto Web JSF601.
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:
- Haga copia de seguridad de toda el área de trabajo.
- Si está trabajando con un repositorio compartido, reserve o bloquee
todos los proyectos que corresponda.
Para acceder al asistente de migración J2EE, siga estos pasos:
- 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.
- En el menú emergente, seleccione Migrar ->
Asistente de migración J2EE.
- 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:
- Para poder migrar los servicios Web seguros (de J2EE 1.3 a J2EE
1.4), hay que migrar manualmente los archivos de enlace y extensión
seguros. Encontrará los detalles en; Migrar servicios Web seguros.
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.
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:
- Pulse dos veces en el archivo webservices.xml para abrir el editor
de servicios Web.
- Seleccione la pestaña Configuraciones de enlace para editar
el archivo de enlace.
- 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.
- Seleccione la pestaña Extensión para editar el archivo de
extensión.
- 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.
- Guarde los cambios y salga del editor.
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.
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.
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.
- Del objeto ResourceAdaptor al objeto OutboundResourceAdaptor, se han
trasladado los elementos siguientes:
- reauthenticationSupport
- transactionSupport
- Del objeto ResourceAdaptor al objeto ConnectionDefinition, se han
trasladado los elementos siguientes:
- managedConnectionFactoryClass
- connectionFactoryInterface
- connectionFactoryImplClass
- connectionInterface
- connectionImplClass
- El objeto OutboundResourceAdaptor contiene una lista de definiciones de
conexión, que son los objetos ConnectionDefinition. Por lo tanto, el
objeto ConnectionDefinition se añade a la lista de objetos
ConnectionDefinition que hay en el objeto OutboundResourceAdaptor.
- El objeto OutboundResourceAdaptor se encuentra en el objeto
ResourceAdaptor.
- El objeto AuthenticationMechanism ha sufrido algunos cambios en JCA
1.5, en los que el elemento customAuthMechType se sustituye por el
elemento authenticationMechanism, y el elemento authenticationType se
sustituye por el elemento authenticationMechanism.
- El atributo description del objeto ResourceAdaptor se sustituye por un
objeto Description, en el que la serie del atributo description se establece
en el elemento value del objeto Description para los objetos siguientes:
- SecurityPermission
- AuthenticationMechanism
- ConfigurationProperties
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:
- Servlets con JAXR-RPC
- Servlets con SOAP directo
- Beans de sesión sin estado
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:
- Descriptor de servicios Web
- Descriptor de cliente de servicios Web
- Descriptor de correlación de JAX-RPC
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.
- Descriptor de servicios Web (webservices.xml)
El descriptor de despliegue webservices.xml está presente en los
proyectos Web que contienen servicios Web J2EE. El elemento
<wsdl-port> y el elemento <soap-header>
contienen, ambos, nombres calificados, y su contenido migrará al formato
J2EE 1.4.
Por ejemplo, supongamos que, antes de la migración,
<wsdl-port> viene representado de la siguiente manera:
<wsdl-port>
<namespaceURI>http://addressbook.webservice</namespaceURI>
<localpart>AddressBook</localpart>
</wsdl-port>
Después de la migración, <wsdl-port> sería:
<wsdl-port xmlns:pfx="http://addressbook.webservice">pfx:AddressBook</wsdl-port>
En todos los nombres calificados que se migran, se utiliza "pfx" como
prefijo del espacio de nombres.
- Descriptor de cliente de servicios Web
(webservicesclient.xml)
En J2EE 1.3, el descriptor de despliegue
webservicesclient.xml está presente en los proyectos Web y proyectos
de cliente de aplicaciones que contienen clientes de servicios Web
J2EE. Durante la migración de J2EE 1.3 a 1.4, el
contenido de webservicesclient.xml migra y se traslada al descriptor de
despliegue del proyecto. El proceso que se produce es el
siguiente:
- En el caso de los proyectos Web, todos los elementos
<service-ref> de webserivcesclient.xml se trasladan al
elemento <web-app> de web.xml.
- En el caso de los proyectos de cliente de aplicaciones, todos los
elementos <service-ref> de webservicesclient.xml se
trasladan al elemento <application-client> de
application-client.xml.
- El descriptor webservicesclient.xml se suprime.
El elemento <service-qname> y el elemento
<soap-header> contienen, ambos, nombres calificados, y su
contenido migrará al formato J2EE 1.4. Por ejemplo,
supongamos que, antes de la migración, <service-qname>
viene representado de la siguiente manera:
<service-qname>
<namespaceURI>http://addressbook.webservice</namespaceURI>
<localpart>AddressBookService</localpart>
</service-qname>
Después de la migración, <service-qname>
sería:
<service-qname xmlns:pfx="http://addressbook.webservice">pfx:AddressBookService</service-qname>
En todos los nombres calificados que se migran, se utiliza "pfx" como
prefijo del espacio de nombres.
- Descriptor de correlación JAX-RPC
Los descriptores de despliegue webservices.xml y
webservicesclient.xml pueden hacer referencia, ambos, a uno o más
descriptores de despliegue de correlación JAX-RPC.
En el archivo webservices.xml, las referencias están en el
elemento <jaxrpc-mapping-file> de cada elemento
<webservice-description>. En el archivo
webservicesclient.xml, las referencias están en el elemento
<jaxrpc-mapping-file> de cada elemento
<service-ref>.
Durante la migración de J2EE 1.3 a 1.4, migran todos los
descriptores de despliegue de correlación JAX-RPC a los que se haga
referencia en webservices.xml y webservicesclient.xml. En
la migración, todos los nombres calificados migran al formato J2EE
1.4 (en los apartados anteriores sobre webservices.xml y
webservicesclient.xml encontrará ejemplos de nombres calificados
después de la migración).
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.
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.
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.
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:
- Los servidores WebSphere Application Server V4.x han dejado de ser
entornos de prueba soportados. Sin embargo, las aplicaciones del nivel
de especificación J2EE 1.2 todavía se pueden exportar y desplegar
manualmente a efectos de prueba en los servidores remotos de la
V4.x.
- Se ha añadido el servidor WebSphere Application Server V6.0 a
modo de entorno de prueba instalable. Este servidor permite ejecutar
aplicaciones del nivel de especificación J2EE 1.4.
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