Guía para la migración de IBM Rational Application 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 Application Developer V6.0
Capítulo 3. Actualizar recursos de tiempo de ejecución de Faces para proyectos de portlet de Rational Application Developer V6.0
Capítulo 4. Migrar proyectos J2EE
Capítulo 5. Migrar a Portal Tools de Rational Application Developer V6.0
Migrar los portlets de WebSphere Portal V4.2 a la V5.x
Actualizar recursos de tiempo de ejecución de Faces en un proyecto de portlet
Capítulo 6. Cambios realizados en los entornos de prueba de WebSphere
En esta documentación se facilitan instrucciones para migrar de
WebSphere Studio Application Developer V5.1.x a Rational
Application Developer V6.0.
Podrá encontrar información adicional en los temas:
En la ayuda en línea encontrará información sobre cómo utilizar
Rational Application Developer.
Consulte el sitio www.ibm.com/developerworks/rational
para obtener documentación actualizada.
Para obtener información sobre cómo migrar de las versiones
anteriores de WebSphere Studio a la V5.x o sobre cómo migrar de
VisualAge para Java a WebSphere Studio, vaya a www.ibm.com/software/awdtools/studioappdev/support/
y busque "migration guide" (guía de migración).
Para migrar de WebSphere Studio V5.1.x:
- 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 Application Developer. Consulte la
guía de instalación (archivo install.html) que está
disponible en el directorio raíz del primer CD del producto.
- Recomendación: por omisión, la primera vez que
inicia Rational Application Developer, se le pedirá que confirme que desea
utilizar un área de trabajo llamada rationalsdp6.0\workspace.
Es decir, el diálogo de lanzamiento del área de trabajo señala hacia
un directorio que no es el área de trabajo de WebSphere Studio. Para
explorar el nuevo entorno antes de migrar la antigua área de trabajo,
acepte el valor predeterminado o bien especifique otro nombre de directorio
nuevo cuando inicie Rational Application Developer. Le interesará
hacerlo para, por ejemplo, poder crear uno o dos proyectos de prueba,
enterarse de las novedades (Ayuda -> Bienvenido),
seguir las instrucciones de algunas guías de aprendizaje (Ayuda
-> Galería de guías de aprendizaje) o bien experimentar
con algunos de los nuevos ejemplos (Ayuda -> Galería
de ejemplos).
- 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 Application Developer con la antigua área de
trabajo. Verá un indicador de progreso que confirma que los
proyectos se están migrando automáticamente.
Notas: Durante la migración del área de trabajo, se
abrirá un diálogo Problemas con el mensaje No se ha
podido restaurar el diseño del entorno de trabajo. Razón:
se produjeron problemas al restaurar el entorno de trabajo. Los
mensajes de error no afectan a la migración satisfactoria del área de
trabajo. Tome nota de la perspectiva que no se ha podido
restaurar; para ello, pulse el botón Detalles del
diálogo de error, y después pulse Aceptar para cerrar el
diálogo.
Para restaurar la perspectiva:
- 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
Application Developer V6.0. All EGL projects are safely migrated
without this perspective in Rational Application Developer V6.0.
Si ha utilizado la perspectiva Web EGL, haga lo siguiente:
- 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 Application 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
Application Developer V6.0 utilizando la característica Intercambio
de proyectos se migran automáticamente a V6.0. La
característica Intercambio de proyectos estaba disponible en WebSphere
Studio V5.1.2 y era un conector opcional para
V5.1.1.
Notas:
- Si ha utilizado Portal Toolkit V5.0.2.2 con
WebSphere Studio V5.1.2 para desarrollar proyectos
portlet, el área de trabajo migrará automáticamente para ser
compatible con Rational Application Developer. Hallará más
información en: Capítulo 5, Migrar a Portal Tools de Rational Application Developer V6.0.
- 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 Application 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
Application Developer V6.0. Si ha creado conexiones JDBC
mediante el controlador JDBC de DB2 Net, no podrá volver a conectar en
Rational Application Developer V6.0. Será preciso que cambie
la conexión para que utilice uno de los controladores JDBC permitidos en el
producto. En la ayuda en línea hallará más información
sobre los controladores JDBC que se pueden utilizar en la V6.0.
- Si tiene contenido de un archivo Web o XML que haya migrado de WebSphere
Studio Application Developer V5.1.x y que utilizaba el juego de
caracteres Shift_JIS e incluía caracteres seleccionados por el proveedor,
debe especificar en su lugar el juego de caracteres Windows-31J.
- Si ha instalado conectores de algún proveedor con el producto WebSphere
Studio Application Developer V5.1.x, deberá obtener los
correspondientes conectores de la V6.0 y volver a instalarlos.
- Si ha instalado entornos de prueba unitaria de WebSphere V5.x que
sean de un nivel anterior al instalar Rational Application Developer y si
además utiliza el servicio de mensajería incorporada, debe actualizarlo,
instalando la versión que viene con Rational Application Developer.
En la guía de instalación encontrará los detalles para
instalar el servicio de mensajería incorporada.
- Si utiliza características que requieran Agent Controller,
actualícelo, instalando la versión que viene con Rational Application
Developer. Encontrará los detalles en la guía de
instalación.
- 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 Application Developer, se realiza una
migración automática del área. Una vez que haya migrado un
área de trabajo, ya no podrá abrirla en WebSphere Studio Application
Developer. Sin embargo, los proyectos del área de trabajo de
V6.0 todavía se pueden compartir con WebSphere Studio
V5.1.x, ya sea utilizando un sistema de gestión de código
fuente (SCM) (como puede ser Rational ClearCase), importando y exportando el
proyecto utilizando el Intercambio de proyectos o bien importando los
archivados y exportando los proyectos. Importante: las
aplicaciones portlet de Portal Toolkit V5.0.2.2 que se
migren a Portal Tools de Rational Application Developer V6.0 no
serán retrocompatibles.
- Nota:
- Los siguientes puntos no atañen a las aplicaciones portlet.
Los proyectos existentes en V5.1.x que se carguen en
V6.0 a partir de un sistema SCM o de otro desarrollador utilizando el
Intercambio de proyectos serán compatibles y se podrán compartir con
V5.1.x, siempre y cuando no se lleve a cabo ninguna
de estas acciones:
- 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.
- Llevar a cabo la acción "Eliminar compatibilidad" en un proyecto de
aplicación de empresa (si la aplicación de empresa o algunos de sus
módulos o proyectos de utilidad deben ser compatibles con WebSphere Studio
Application Developer V5.1.x).
Cuando se abre un proyecto de V5.1.x en el área de trabajo
de Rational Application Developer V6.0, se crea automáticamente un
archivo .compatibility en el directorio del proyecto. El
producto Rational Application Developer utiliza el archivo
.compatibility para hacer un seguimiento de las indicaciones de la hora
de los recursos del proyecto al migrarlos. No debe editarlo ni
suprimirlo.
Encontrará información sobre cómo inhabilitar la compatibilidad
con WebSphere Studio Application Developer V5.1.x en: Inhabilitar la compatibilidad con WebSphere Studio V5.1.x.
Consideraciones sobre Eclipse
Esta versión de Rational Application Developer está basada en Eclipse
V3.0. Si desarrolla conectores propios, debe informarse sobre
los cambios realizados en la plataforma antes de migrar.
Los detalles están en el archivo readme del subdirectorio
eclipse\readme de la ubicación de instalación de Rational Application
Developer V6.0. Los apartados del archivo readme que resultan
interesantes de cara a la migración son:
- Compatibilidad 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 Application Developer V6.0 se
habilita por medio de los metadatos que se añaden automáticamente a los
archivos .project en el momento de migrar el área de trabajo de
V5.1.x. De igual modo, si crea un módulo o una
aplicación J2EE 1.2 o J2EE 1.3 en Rational Application
Developer V6.0, se añaden automáticamente metadatos de
construcción al archivo
.project para proporcionar compatibilidad con
V5.1.x. No debe editar ni suprimir esta información
directamente.
- Nota:
- Los metadatos de compatibilidad harán que se visualicen o anoten mensajes
que advierten de que faltan constructores cuando un nuevo módulo o
aplicación J2EE 1.2 y J2EE 1.3 creado en V6.0 se
utilice en WebSphere Studio Application Developer V5.1.x, donde
no están disponibles los constructores de V6.0. Estos
mensajes son normales; no hace falta hacerles caso.
Mientras estén presentes los metadatos de compatibilidad, recibirá
mensajes que advierten de que faltan constructores cuando los proyectos de
Rational Application Developer V6.0 se cargan de nuevo en WebSphere
Studio V5.1.x. A continuación se proporciona un
mensaje de ejemplo que advierte de la falta de un constructor:
!ENTRY org.eclipse.core.resources 2 1 Sep 06, 2004 19:55:20.592
!MESSAGE Omitiendo constructor com.ibm.wtp.j2ee.LibCopyBuilder para proyecto Test60EARWeb.
El constructor no se encuentra en la instalación o pertenece a una naturaleza de proyecto que falta o está inhabilitada.
Estos mensajes son normales; no hace falta hacerles caso.
Cuando tenga la seguridad de que ya no necesita trabajar más con un
proyecto dado en WebSphere Studio V5.1.x, puede evitar que
aparezcan estos mensajes inhabilitando la
retrocompatibilidad en ese proyecto.
Importante: los nuevos proyectos de la especificación
J2EE 1.2 o J2EE 1.3 creados en V6.0 son retrocompatibles
con WebSphere Studio V5.1.x, pero una vez que los proyectos se
hayan cargado en WebSphere Studio, hará falta realizar algunos pasos
manuales para poder trabajar con ellos. Son pasos necesarios porque los
destinos de tiempo de ejecución en los nuevos proyectos de la
especificación J2EE 1.2 o J2EE 1.3 creados en V6.0 no
son directamente retrocompatibles en los servidores destino de
V5.1.x. Los pasos manuales que deben realizarse cuando un
proyecto nuevo de V6.0 se carga en V5.1.x son los
siguientes:
- 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
Application Developer V6.0 y WebSphere Studio Application Developer
V5.1.x. Después de haber comprometido los cambios en
el sistema SCM, los proyectos J2EE serán interoperativos entre
V5.1.x y V6.0 mediante un sistema SCM.
- Nota:
- Si el servidor destino se vuelve a establecer en Rational Application
Developer V6.0, se perderá la compatibilidad de los proyectos J2EE y
habrá que restablecerla.
Compatibilidad de los diagramas UML
Los diagramas UML que ya existían en WebSphere Studio Application
Developer V5.1.x son compatibles con las versiones posteriores y
se pueden abrir en modalidad solo de lectura en Rational Application Developer
V6.0. En V6.0, el asistente de migración J2EE migra
automáticamente los diagramas UML creados en los proyectos J2EE de
V5.1.x durante la migración de la estructura del proyecto
J2EE. Una vez migrados, los diagramas UML se pueden editar en Rational
Application Developer V6.0.
- Nota:
- Los diagramas UML de un área de trabajo migrada al producto Rational
Application Developer V6.0 o creada en él no se pueden abrir en
WebSphere Studio Application Developer V5.1.x.
La compatibilidad con WebSphere Studio Application Developer
V5.1.x se puede eliminar totalmente de un proyecto de
aplicación de empresa creado en Rational Application Developer V6.0
o de un proyecto de aplicación de empresa que se haya migrado de una
versión anterior de WebSphere Studio. Solo debe inhabilitar la
compatibilidad con WebSphere Studio V5.1.x si está seguro de
que el proyecto de aplicación de empresa ya no debe interoperar ni ser
compatible con la V5.1.x.
Para eliminar la compatibilidad con WebSphere Studio Application Developer
V5.1.x:
- 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 Application Developer V5.1.x.
Los recursos de tiempo de ejecución de JavaServer Faces enviados con
WebSphere Studio Application Developer V5.1.x se han actualizado
para Rational Application Developer V6.0.1. Si desea
seguir desarrollando proyectos Web creados con esta versión anterior del
producto, es recomendable que actualice los recursos de tiempo de ejecución
de Faces a los últimos niveles.
En Rational Application Developer V6.0.1, las actualizaciones
de recursos de tiempo de ejecución de Faces ocurren automáticamente
cuando se importa un proyecto Web o se abre un área de trabajo que contiene
recursos no actualizados. Después de importar un proyecto Web o
abrir un área de trabajo de WebSphere Studio Application Developer
V5.1.x a Rational Application Developer V6.0.1, se
le solicitará actualizar los recursos de tiempo de ejecución de Faces a
los últimos niveles.
Actualizar automáticamente recursos de tiempo de ejecución
Para actualizar automáticamente los recursos de tiempo de
ejecución de Faces para un proyecto Web:
- Importe un proyecto Web (o un área de trabajo) con contenido de Faces
de WebSphere Studio Application Developer V5.1.x. Se abre
la ventana Migración de proyectos.
- Nota:
- Si la ventana Migración de proyectos no se abre, el valor de preferencia
de construcción automática esté probablemente inhabilitado. En
el Explorador de proyecto, pulse con el botón derecho del ratón sobre el
proyecto Web y seleccione Construir ->
Proyecto; el proceso de reconstrucción de un proyecto abre
la ventana Migración de proyectos.
- 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 Application 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 Application Developer V5.1.x se
han actualizado para Rational Application Developer
V6.0.1. Si desea seguir desarrollando proyectos Web
creados con esta versión anterior del producto, es recomendable que
actualice los recursos de tiempo de ejecución del cliente Faces a los
últimos niveles.
En Rational Application Developer V6.0.1, las actualizaciones
de recursos de tiempo de ejecución de cliente Faces ocurren
automáticamente cuando se importa un proyecto Web o se abre un área de
trabajo que contiene recursos no actualizados. Después de importar
un proyecto Web o abrir un área de trabajo de WebSphere Studio Application
Developer V5.1.x a Rational Application Developer
V6.0.1, se le solicitará actualizar los recursos de tiempo de
ejecución del cliente Faces a los últimos niveles.
Actualizar automáticamente recursos de tiempo de ejecución
Para actualizar automáticamente los recursos de tiempo de
ejecución del cliente Faces para un proyecto Web:
- Importe un proyecto Web (o un área de trabajo) con contenido de cliente
Faces de WebSphere Studio Application Developer V5.1.x.
Se abre la ventana Migración de proyectos.
- Nota:
- Si la ventana Migración de proyectos no se abre, el valor de preferencia
de construcción automática esté probablemente inhabilitado. En
el Explorador de proyecto, pulse con el botón derecho del ratón sobre el
proyecto Web y seleccione Construir ->
Proyecto; el proceso de reconstrucción de un proyecto abre
la ventana Migración de proyectos.
- 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 Application Developer V6.0 añadirá la barra inclinada
"/" cuando se cree un proyecto Struts nuevo; sin embargo, debe
añadirse manualmente al migrar de WebSphere Studio V5.1x.
Siga estos pasos para corregir en V6.0 el descriptor de despliegue
de un proyecto Web de Struts creado en WebSphere Studio
v5.1.x:
- 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 Application 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 Application 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
Application Developer V6.0. Deberá tener presentes esos
cambios para poder utilizar las herramientas con los proyectos después de
la migración. Es posible que deba cambiar o restaurar algunos
valores.
Migrar áreas de trabajo y configuraciones de lanzamiento
Cuando un área de trabajo de la V5.1.x del producto
WebSphere Studio Application Developer se abre en Rational Application
Developer V6.0, hay unas cuantas configuraciones de lanzamiento del
depurador asociadas al área de trabajo que no migrarán
automáticamente; son las siguientes:
- 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 Application 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 Application
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 Application 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 Application Developer
V6.0. Si migra un área de trabajo de WebSphere Studio
Application Developer V5.1.x, tendrá que modificar el JRE
instalado para que señale hacia la ubicación correcta para poder lanzar
una sesión de depuración XSLT correspondiente a dicha área.
Para ello, puede elegir una de estas acciones:
- 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 Application 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 Application 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 Application 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 Application Developer V6.0 se han actualizado
para Rational Application Developer V6.0.1. Si desea
seguir desarrollando proyectos Web creados con esta versión anterior del
producto, es recomendable que actualice los recursos de tiempo de ejecución
de Faces y del cliente Faces a los últimos niveles.
En Rational Application Developer V6.0.1, las actualizaciones
de recursos de tiempo de ejecución de Faces y del cliente Faces ocurren
automáticamente cuando se importa un proyecto Web o se abre un área de
trabajo que contiene recursos no actualizados. Después de importar
un proyecto Web o abrir un área de trabajo de Rational Application
Developer V6.0.x a Rational Application Developer
V6.0.1, se le solicitará actualizar estos recursos de tiempo
de ejecución a los últimos niveles.
Actualizar automáticamente recursos de tiempo de ejecución
Para actualizar automáticamente los recursos de tiempo de
ejecución de Faces y del cliente Faces para un proyecto Web:
- Importe un proyecto Web (o un área de trabajo) con contenido de Faces o
de cliente Faces de Rational Application Developer V6.0. Se abre
la ventana Migración de proyectos.
- Nota:
- Si la ventana Migración de proyectos no se abre, el valor de preferencia
de construcción automática esté probablemente inhabilitado. En
el Explorador de proyecto, pulse con el botón derecho del ratón sobre el
proyecto Web y seleccione Construir ->
Proyecto; el proceso de reconstrucción de un proyecto abre
la ventana Migración de proyectos.
- 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.
Los recursos de tiempo de ejecución de JavaServer Faces y el cliente
Faces enviados originalmente en Rational Application Developer V6.0 se
han actualizado para Rational Application Developer
V6.0.1. Si desea seguir desarrollando proyectos de
portlet creados con esta versión anterior del producto, es recomendable que
actualice los recursos de tiempo de ejecución de Faces y del cliente Faces
a los últimos niveles.
En Rational Application Developer V6.0.1, las actualizaciones
de los recursos de tiempo de ejecución de Faces y del cliente Faces se
producen automáticamente cuando se importa un proyecto de portlet o se abre
un área de trabajo que contiene recursos de Faces o del cliente Faces no
actualizados. Después de importar un proyecto de portlet o de abrir
un área de trabajo de Rational Application Developer V6.0 en
Rational Application Developer V6.0.1, se le solicitará
actualizar estos recursos de tiempo de ejecución a los niveles más
recientes.
Actualizar automáticamente recursos de tiempo de ejecución
Para actualizar automáticamente los recursos de tiempo de
ejecución de Faces y del cliente Faces para un proyecto de portlet:
- Importe un proyecto de portlet (o un área de trabajo) con contenido de
Faces o del Cliente Faces de Rational Application Developer
V6.0. Se abre la ventana Migración de proyectos.
- Nota:
- Si la ventana Migración de proyectos no se abre, el valor de preferencia
de construcción automática esté probablemente inhabilitado. En
el Explorador de proyecto, pulse con el botón derecho del ratón sobre el
proyecto de portlet y seleccione Construir ->
Proyecto; el proceso de reconstrucción de un proyecto abre
la ventana Migración de proyectos.
- Si tiene otros proyectos de portlet con contenido de Faces o del cliente
Faces en el área de trabajo, marque Aplicar esta opción a
cualesquiera otros proyectos que necesiten actualizarse y se
actualizarán todos los proyectos de portlet.
- 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 de portlet o reiniciar el entorno de trabajo antes de reconstruir el
proyecto de portlet. Si ha inhabilitado las construcciones
automáticas, pulse con el botón derecho del ratón sobre el proyecto
de portlet 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.
- Para actualizar los recursos de tiempo de ejecución Faces
específicos del portlet, jsf-portlet.jar y jsf-wp.jar, debe
seguir los pasos de actualización manual que se indican a
continuación.
Actualizar manualmente recursos de tiempo de ejecución
Para actualizar manualmente los recursos de tiempo de
ejecución de Faces y del cliente Faces para un proyecto de portlet:
- Cree un proyecto de portlet nuevo llamado JSFP601. Este
proyecto tan solo lo utilizará como origen de los recursos de tiempo de
ejecución más recientes; puede suprimirse una vez realizada la
actualización.
- En el explorador de proyectos, pulse el proyecto JSFP601 con el
botón derecho del ratón y seleccione Propiedades en el
menú.
- Pulse Características de proyecto Web, seleccione
Añadir infraestructura de cliente Faces para proyecto de portlet
y pulse Aceptar.
- Para cada proyecto de portlet 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:
- jsf-api.jar
- jsf-ibm.jar
- jsf-impl.jar
- jsf-portlet.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
JSFP601 y péguelo en el proyecto original en la misma
ubicación. En algunas configuraciones no hará falta que todos
estos archivos JAR estén presentes en el proyecto; no copie un archivo
JAR determinado si no estaba en el proyecto original.
- Si el proyecto portlet utiliza la API de portlet de IBM o un componente de
enlace personal, copie el archivo jsf-wp.jar en el proyecto
original.
- Si copia el archivo odc-jsf.jar, copie asimismo el archivo
odc-jsf-portlet.jar.
- Suprima el proyecto de portlet JSFP601.
El asistente de migración J2EE se ha actualizado en Rational Application
Developer V6.0 para migrar los proyectos J2EE al nivel de
especificación J2EE 1.4. El asistente de migración J2EE
permite migrar de las especificaciones J2EE 1.2 y 1.3 al nivel
de especificación J2EE 1.4. sea cual sea el tipo de módulo
J2EE.
Los detalles sobre cómo migrar artefactos de los niveles de
especificación J2EE 1.2 y 1.3 al nivel de especificación
J2EE 1.4 están en: Migración del nivel de especificación J2EE 1.2 al nivel de especificación J2EE 1.4 y Migración del nivel de especificación J2EE 1.3 al nivel de especificación J2EE 1.4.
- Nota:
- Antes de utilizar el asistente de migración J2EE, le recomendamos
encarecidamente que tome las siguientes medidas:
- 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.
- Para migrar proyectos Enterprise JavaBeans (de EJB 1.1 a EJB
2.1), hay que realizar algunos pasos manuales. Encontrará los
detalles en; Migrar proyectos JavaBeans (de EJB 1.1 a EJB 2.1).
En la ayuda en línea hallará todos los detalles de cómo utilizar
el asistente de migración J2EE. Los cambios que presenta el
asistente se describen en: Cambios que presenta el asistente de migración J2EE en Rational Application Developer V6.0.
Para obtener los detalles sobre los cambios que se realizan en los
artefactos de los niveles de especificación J2EE 1.3 y J2EE
1.2 cuando se migran a J2EE 1.4, consulte: Migración del nivel de especificación J2EE 1.3 al nivel de especificación J2EE 1.4 y Migración del nivel de especificación J2EE 1.2 al nivel de especificación J2EE 1.4.
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 permite migrar los descriptores de
despliegue de beans de empresa de los recursos EJB del nivel de
especificación J2EE 1.3 al nivel de especificación J2EE
1.4. Los beans de sesión sin estado y los beans controlados
por mensajes migran a J2EE 1.4.
Migrar beans de sesión
Con el asistente de migración J2EE, los beans de sesión sin estado
que estén definidos como interfaces de punto final de servicio (SEI) en el
descriptor webservices.xml de un proyecto EJB en J2EE 1.3 se
pueden migrar al nivel de especificación J2EE 1.4,
estableciéndose para ello nuevas interfaces de punto final de servicio en
los beans de sesión sin estado.
La especificación J2EE 1.4 exige que se defina una SEI en un bean
de sesión sin estado que deba utilizarse como punto final de servicios
Web. Durante la migración de un archivo JAR EJB, todos los beans de
sesión del proyecto EJB obtienen el nuevo punto final de servicio
establecido en el nombre que se utiliza en el descriptor
webservices.xml del proyecto EJB. En el siguiente ejemplo, se ve
cómo son los metadatos de un proyecto EJB antes y después de migrarlo al
nivel de especificación J2EE 1.4.
Proyecto EJB de J2EE 1.3: descriptor
webservices.xml con un bean de sesión sin estado que se
utiliza como punto final de servicios Web antes de la migración
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE webservices PUBLIC "-//IBM Corporation, Inc.//DTD J2EE Web services 1.0//EN"
"http://www.ibm.com/webservices/dtd/j2ee_web_services_1_0.dtd">
<webservices id="WebServices_1084831328093">
<webservice-description id="WebServiceDescription_1084831328093">
<webservice-description-name>EchoEJBService</webservice-description-name>
<wsdl-file>META-INF/wsdl/EchoEJB.wsdl</wsdl-file>
<jaxrpc-mapping-file>META-INF/EchoEJB_mapping.xml</jaxrpc-mapping-file>
<port-component id="PortComponent_1084831328103">
<port-component-name>EchoEJB</port-component-name>
<wsdl-port id="WSDLPort_1084831328103">
<namespaceURI>http://test</namespaceURI>
<localpart>EchoEJB</localpart>
</wsdl-port>
<service-endpoint-interface>test.EchoEJB</service-endpoint-interface>
<service-impl-bean id="ServiceImplBean_1084831328103">
<ejb-link>EchoEJB</ejb-link>
</service-impl-bean>
</port-component>
</webservice-description>
</webservices>
Los códigos <service-endpoint-interface> y
<service-impl-bean> del ejemplo anterior definen el bean de
sesión sin estado "EchoEJB" como punto final de servicio en el descriptor
de servicios Web (webservices) en el nivel de especificación J2EE
1.3 antes de la migración.
Proyecto EJB de J2EE 1.4: descriptor de despliegue EJB
del mismo bean de sesión sin estado "EchoEJB" con la interfaz de punto
final de servicio (SEI) creada por el proceso de migración
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar>
<ejb-jar id="ejb-jar_ID" version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
<display-name>
EchoEJBProject</display-name>
<enterprise-beans>
<session id="EchoEJB">
<ejb-name>EchoEJB</ejb-name>
<home>test.EchoEJBHome</home>
<remote>test.EchoEJB</remote>
<service-endpoint>test.EchoEJB</service-endpoint>
<ejb-class>test.EchoEJBBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
El código <service-endpoint> del ejemplo anterior
define el bean "EchoEJB" como punto final de servicio en el nivel de
especificación J2EE 1.4 después de la migración.
Migrar beans controlados por mensajes
El asistente de migración de J2EE soporta la migración de beans
controlados por mensaje de EJB 2.0 a EJB 2.1.
Los beans controlados por mensajes se introdujeron en EJB 2.0 para
dar soporte al proceso de mensajes asíncronos procedentes de un servicio de
mensajería Java (JMS). La especificación EJB 2.1 amplía
la definición del bean controlado por mensajes para que pueda admitir
cualquier sistema de mensajería, no tan solo el sistema JMS.
- Nota:
- Los beans controlados por mensaje que se han migrado del nivel de
especificación EJB 2.0 a EJB 2.1 y que se despliegan en
WebSphere Application Server Versión 6 deben desplegarse contra un recurso
de JCA (Java Connector Architecture) 1.5 en lugar de un puerto de
escucha (como en WebSphere Application Server Versión 5). Debe
utilizar el Editor de descriptores de despliegue para cambiar los valores de
Enlaces de WebSphere para que los beans controlados por mensaje de EJB
2.1 utilicen un adaptador JCA. Consulte Configurar un bean controlado por mensaje de EJB 2.1 para que utilice un adaptador JCA.
Los artefactos migrados de los beans controlados por mensajes de EJB
2.0 son:
- acknowledgeMode
- messageSelector
- destinationType
- subscriptionDurablity
Algunos de los elementos de los beans controlados por mensajes de EJB
2.0 se sustituyen por propiedades del elemento
activation-config. Los nombres y valores que se utilizan en
la propiedad activation-config para describir el servicio de
mensajería varía en función del tipo de servicio de mensajería que
se utilice. Sin embargo, la especificación EJB 2.1 define un
conjunto de propiedades fijas para los beans controlados por mensajes basados
en JMS.
En el siguiente ejemplo, se establece una comparación entre los
elementos de un bean de ejemplo de EJB 2.0 y los elementos tal como
serían en EJB 2.1.
Ejemplo de los elementos de un bean controlado por mensajes en EJB
2.0:
<message-driven id="Mdb20">
<ejb-name>Mdb</ejb-name>
<ejb-class>ejbs.MdbBean</ejb-class>
<transaction-type>Bean</transaction-type>
<message-selector>mdbMessage</message-selector>
<acknowledge-mode>Auto-acknowledge</acknowledge-mode>
<message-driven-destination>
<destination-type>javax.jms.Topic</destination-type>
<subscription-durability>Durable</subscription-durability>
</message-driven-destination>
</message-driven>
Ejemplo de los elementos de un bean controlado por mensajes en EJB
2.1:
<message-driven id="Mdb21">
<ejb-name>Foo/ejb-name>
<ejb-class>ejbs.FooBean</ejb-class>
<messaging-type>javax.jms.MessageListener</messaging-type>
<transaction-type>Bean/transaction-type>
<message-destination-type>javax.jms.Topic</message-destination-type>
<activation-config>
<activation-config-property>
<activation-config-property-name>destinationType</activation-config-property-name>
<activation-config-property-value>javax.jms.Topic</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>subscriptionDurability</activation-config-property-name>
<activation-config-property-value>Durable</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>acknowledgeMode</activation-config-property-name>
<activation-config-property-value>AutoAcknowledge</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>messageSelector</activation-config-property-name>
<activation-config-property-value>fooSelector</activation-config-property-value>
</activation-config-property>
</activation-config>
</message-driven>
Los beans controlados por mensaje que se han migrado del nivel de
especificación Enterprise Java Bean (EJB) 2.0 al EJB 2.1 y
que se despliegan en WebSphere Application Server Versión 6 deben
desplegarse contra un adaptador de recursos Java Connector Architecture (JCA)
1.5 en lugar de un puerto de escucha.
Los pasos siguientes describen cómo cambiar el descriptor de despliegue
de los beans controlados por mensaje de EJB 2.1 para que utilicen un
adaptador JCA:
- Abra el proyecto EJB en el Explorador de proyectos.
- Efectúe una doble pulsación sobre el archivo Descriptor de
despliegue del proyecto EJB en el Explorador de proyectos. Se
abre el editor de descriptores de despliegue EJB.
- Pulse la pestaña Bean para abrir la página
Bean.
- Para cada bean controlado por mensaje EJB 2.1 del proyecto EJB,
haga lo siguiente:
- Seleccione el bean gestionado por mensaje EJB 2.1 en la lista de
beans del lado izquierdo de la página Bean.
- Bajo la cabecera de Enlaces de WebSphere, seleccione el
botón Adaptador de JCA.
- Especifique las propiedades de despliegue de los enlaces:
- Nombre JNDI de ActivationSpec.
Teclee el nombre JNDI de la especificación de activación J2C que debe
utilizarse para desplegar este bean controlado por mensaje. Este nombre
debe coincidir con el nombre de una especificación de activación J2C
definida en WebSphere Application Server.
- Alias de autorización de ActivationSpec.
El nombre de un alias de autenticación J2C utilizado para la
autenticación de conexiones con el adaptador de recursos de JCA. Un
alias de autenticación J2C especifica el ID de usuario y la contraseña
utilizados para autenticar la creación de una conexión nueva con el
adaptador de recursos JCA.
- Nombre JNDI de destino.
Teclee el nombre JNDI que el bean controlado por mensaje utiliza para
buscar el destino JMS en el espacio de nombres JNDI.
- Guarde los cambios y cierre el editor de descriptores de
despliegue.
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 y en los proyectos EJB 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, proyectos
EJB 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.
- En el caso de los proyectos EJB, todos los elementos
<service-ref> que haya en un elemento
<component-scoped-refs> de webserviceclient.xml se
trasladan al correspondiente elemento <enterprise-bean> de
ejb-jar.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 4, Migrar proyectos J2EE.
En este apartado se explica cómo migrar un proyecto EJB del nivel de
especificación EJB 1.1 al nivel de especificación EJB
2.1.
Para migrar un proyecto EJB de EJB 1.1 a EJB 2.1, hay que
migrar los beans de entidad con persistencia gestionada por contenedor
(CMP).
No se han realizado cambios en los beans de entidad entre los niveles de
especificación J2EE 1.3 y J2EE 1.4. Para migrar los
beans de entidad CMP del nivel de especificación EJB 1.1 al nivel de
especificación EJB 2.1 se sigue el mismo procedimiento que para
migrar un bean de entidad CMP de EJB 1.1 a EJB 2.0. Para
migrar beans de entidad gestionados por contenedor del nivel de
especificación EJB 1.1 al nivel de especificación EJB 2.x,
se realizan estos pasos:
- Convertir el proyecto EJB de EJB 1.1 a
EJB 2.x.
- Migrar el código EJB de EJB 1.1 a EJB
2.x.
- Migrar las referencias que estén definidas
por usuario en EJB 1.1 a referencias locales de EJB
2.x.
Los proyectos de EJB 1.1 se pueden convertir a proyectos de EJB
2.x con el asistente de migración J2EE.
- En la vista Jerarquía J2EE, pulse el proyecto de 1.1 con el
botón derecho del ratón y seleccione Migrar ->
Asistente de migración J2EE.
O bien, si desea conservar el proyecto original de EJB 1.1, puede
crear un proyecto nuevo en EJB 2.x y después importar a este el
archivo JAR del proyecto existente (Archivo ->
Importar -> JAR EJB).
Aunque el proyecto sea un proyecto de EJB 2.x, los beans de entidad
con persistencia gestionada por contenedor (CMP) de EJB 1.1 existentes
o importados siguen siendo beans de EJB 1.1. Es decir, los beans
de entidad CMP no se convierten a EJB 2.x.
El asistente de migración J2EE hace que los beans de empresa de un
proyecto de EJB 2.x migren de 1.1 a 2.x. (Si opta
por migrar los beans de entidad CMP de 1.1 a 2.x, hay que migrar
todos los beans del proyecto de 2.x. Sin embargo, puede optar
por añadir selectivamente vistas de cliente local a estos beans de
2.x migrados).
- El asistente conservará la herencia existente en EJB 1.1 en el
proyecto de EJB 2.x.
- El asistente migrará las relaciones (en propiedad) de EJB 1.1 a
relaciones (estándar) de EJB 2.x, además de otras
ventajas.
- Nota:
- Si tiene asociaciones correlacionadas, se crearán asociaciones de EJB
2.x para las propias asociaciones, pero las correlaciones de cometidos
de las asociaciones pasarán a no ser válidas. Si ejecuta la
validación, observará que se produce un error. Para salir de esta
situación, abra primero el editor de correlaciones y guarde la
correlación. Las correlaciones de cometidos se eliminarán.
Entonces podrá ejecutar de nuevo la validación y volver a correlacionar
los cometidos.
En el caso de los proyectos que se conviertan de EJB 1.1 a EJB
2.x, hay que realizar unos cuantos pasos para migrar el código
existente en EJB 1.1 a EJB 2.x.
- Nota:
- Los beans de EJB 2.x solo se pueden utilizar en un proyecto de EJB
2.x (aunque en un proyecto de 2.x también se pueden utilizar
beans de 1.1).
- Para los beans CMP de 1.1, sustituya cada campo CMP por los
métodos abstractos getXXX y setXXX. (Por lo
tanto, la clase de bean también debe ser abstracta).
- Para los CMP, cree un método abstracto getXXX y
setXXX para la clave primaria.
- Para los métodos de búsqueda CMP de 1.1, cree un método
EJBQL (lenguaje de consulta EJB) para cada método de
búsqueda.
- Nota:
- El lenguaje de consulta EJB tiene las siguientes limitaciones en Rational
Application Developer V6.0:
- Las consultas del lenguaje de consulta EJB en las que intervienen beans
EJB con claves que se componen de relaciones con otros beans EJB no
resultarán válidas y provocarán errores en el momento del
despliegue.
- El soporte del lenguaje de consulta EJB de IBM amplía la
especificación EJB 2.x de diversas maneras, entre ellas las de
relajar algunas restricciones, añadir soporte para más funciones de DB2,
etcétera. Si le interesa la portabilidad entre las bases de datos de
diversos proveedores o entre las herramientas de despliegue EJB, tendrá que
tener cuidado de escribir todas las consultas del lenguaje de consulta EJB de
forma que estén estrictamente de acuerdo con las instrucciones indicadas en
el capítulo 11 de la especificación EJB 2.x.
- Para los métodos de búsqueda CMP de 1.1, devuelva
java.util.Collection, en lugar de
java.util.Enumeration.
- Para los beans CMP de 1.1, cambie todas las apariciones de
this.field = value por setField(value) en el
método ejbCreate() y en cualquier otra parte del
código.
- Actualice el manejo de excepciones (comportamiento de la retrotracción)
para las excepciones que no sean de la aplicación:
- Lance javax.ejb.EJBException, en lugar de
java.rmi.RemoteException, para informar de las
excepciones que no sean de la aplicación.
- En EJB 2.x y 1.1, todas las excepciones que no sean de la
aplicación y que haya lanzado la instancia provocan la retrotracción de
la transacción en la que se ejecutaba la instancia, así como el descarte
de la instancia.
- Actualice el manejo de excepciones (comportamiento de la retrotracción)
para las excepciones de la aplicación:
- En EJB 2.x y 1.1, una excepción de la aplicación no
hace que el contenedor retrotraiga automáticamente una
transacción.
- En EJB 1.1, el contenedor realiza la retrotracción solamente si
la instancia se invocó con el método setRollbackOnly() en el
objeto EJBContext.
- Actualice los valores CMP de los valores predeterminados específicos de
la aplicación para que estén dentro de ejbCreate (no lo haga
utilizando variables globales, porque los contenedores de EJB 1.1
establecen todos los campos en valores predeterminados genéricos antes de
llamar a ejbCreate, que sobrescribirá los valores
predeterminados anteriores que sean específicos de la
aplicación).
Al crear relaciones de EJB 1.1, se crearon referencias de EJB a la
vista de cliente remoto. Durante la migración del proyecto EJB
1.1 mediante el asistente de migración J2EE, estas referencias
remotas de EJB correspondientes a las relaciones de EJB 1.1 se eliminan
y se sustituyen por referencias locales de EJB. Las referencias locales
correspondientes a las referencias de EJB definidas por el usuario se tienen
que volver a crear manualmente.
- Nota:
- En EJB 2.x, solo se pueden crear relaciones de EJB si los beans tienen
definida la vista de cliente local y se crean las referencias locales de EJB
para las relaciones de EJB 2.x.
En el caso de las referencias de EJB definidas por usuario, la migración
no se realiza mediante el asistente de migración J2EE.
Sin embargo, para configurar las referencias locales, siga estos pasos:
- Suprima las referencias remotas de EJB existentes en la página
Referencias del editor de descriptores de despliegue.
- Añada una referencia local de EJB en la página Referencias del
editor de descriptores de despliegue.
Durante la migración de la estructura del proyecto mediante el asistente
de migración J2EE, los elementos de método (como son la identidad de
seguridad, la transacción de contenedor, los permisos de método, el
propósito de acceso y los niveles de aislamiento) que sean del mismo tipo
para todos los beans se fusionan para formar un grupo lógico.
A continuación figura un ejemplo de los elementos de método antes y
después de la migración de la estructura del proyecto.
Este es un ejemplo del permiso de método (method-permission) en la
página de código fuente del editor de descriptores de despliegue antes
de migrar la estructura del proyecto.
<method-permission>
<role-name>rol1</role-name>
<role-name>rol2</role-name>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getEJBMetaData</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getHomeHandle</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>java.lang.Object</method-param>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>javax.ejb.Handle</method-param>
</method-params>
</method>
</method-permission>
<method-permission>
<role-name>rol1</role-name>
<role-name>rol2</role-name>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Remote</method-intf>
<method-name>isIdentical</method-name>
<method-params>
<method-param>javax.ejb.EJBObject</method-param>
</method-params>
</method>
</method-permission>
Este es un ejemplo del permiso de método (method-permission) en la
página de código fuente del editor de descriptores de despliegue
después de migrar la estructura del proyecto.
<method-permission>
<role-name>rol1</role-name>
<role-name>rol2</role-name>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getEJBMetaData</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean1</ejb-name>
<method-intf>Home</method-intf>
<method-name>getHomeHandle</method-name>
<method-params>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>>java.lang.Object</method-param>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>javax.ejb.Handle</method-param>
</method-params>
</method>
<method>
<ejb-name>TestBean2</ejb-name>
<method-intf>Remote</method-intf>
<method-name>isIdentical</method-name>
<method-params>
<method-param>javax.ejb.EJBObject</method-param>
</method-params>
</method>
</method-permission>
- Nota:
- Cuando también se selecciona la migración de beans CMP de 1.x a
beans CMP de 2.x, junto con la migración de la estructura del
proyecto, en el asistente de migración J2EE, los propósitos de acceso y
los niveles de aislamiento se eliminan, pero todo lo demás se fusiona
durante la migración. La razón de que se eliminen los
propósitos de acceso y los niveles de aislamiento es que dejan de ser
válidos debido a los cambios realizados en el modelo de extensiones.
Con el nuevo modelo, los propósitos de acceso y los niveles de aislamiento
están definidos en los propósitos de acceso, y existen propósitos de
acceso a nivel de bean y propósitos de acceso a nivel de método.
Siempre es preferible utilizar los propósitos de acceso a nivel de bean que
los propósitos de acceso a nivel de método.
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 Application Developer V6.0 se han realizado cambios en
el asistente de migración J2EE que afectan a la migración de todos los
niveles de la especificación J2EE.
La migración de la estructura del proyecto es opcional
En WebSphere Studio, de la V5.1.x a la V5.1.2,
la migración de la estructura del proyecto debía producirse al mismo
tiempo que la migración del nivel de la especificación J2EE. La
migración de la estructura del proyecto no era opcional al migrar los
niveles de la especificación J2EE.
En el asistente de migración J2EE de Rational Application Developer
V6.0, la opción Migrar estructura de proyecto se puede
seleccionar de manera independiente de la opción Migrar nivel de
especificación J2EE de proyecto. La migración del nivel de
especificación J2EE se puede realizar de forma independiente de la
migración de la estructura del proyecto.
Se necesita un servidor destino
En Rational Application Developer V6.0, para los proyectos J2EE
nuevos y existentes migrados a un nivel superior de la especificación J2EE,
hay que establecer un servidor destino en el proyecto. El
direccionamiento a servidor es el mecanismo predeterminado para establecer la
vía de acceso de clases en un proyecto J2EE de la V6.0. En la
ayuda en línea encontrará información sobre cómo establecer un
servidor destino y utilizar el asistente de migración J2EE.
Los proyectos de Portal Toolkit V5.0.2.2 se
migrarán automáticamente a Rational Application Developer V6.0
Portal Tools migrando el área de trabajo de Portal Toolkit o cargando el
proyecto de un sistema SCM (gestión de código fuente) o importando el
proyecto mediante la característica Intercambio de proyectos. Si se
propone migrar de las versiones anteriores de Portal Toolkit, tendrá que
exportar los proyectos portlet a archivos WAR e importar los archivos WAR a
Portal Tools de Rational Application Developer V6.0.
Antes de migrar las aplicaciones portal, debe instalar la característica
Portal Tools de Rational Application Developer V6.0. Consulte
para ello la guía de instalación.
- Nota:
- Los proyectos portlet no son retrocompatibles.
La migración automática solo se puede realizar para proyectos creados
en Portal Toolkit V5.0.2.2 con WebSphere Studio
V5.1.2. Los detalles sobre la migración trabajo
están en: Capítulo 1, Migrar de WebSphere Studio V5.1, V5.1.1 o V5.1.2.
Si el proyecto de portlet está asociado a un proyecto de aplicación
de empresa, deberá establecer el servidor destino adecuado en el proyecto
EAR. Puede establecer el servidor destino en la página
Propiedades de servidor (Propiedades ->
Servidor).
Durante la migración de los proyectos de Portal Toolkit
V5.0.2.2, tienen lugar algunos cambios adicionales:
- El servidor destino se establece en WebSphere Portal V5.0, si no se
ha establecido ningún servidor destino para el proyecto.
- La vía de construcción de portlet se corrige.
- Se añade una naturaleza de proyecto portlet.
Si se propone migrar de las versiones anteriores de Portal Toolkit,
tendrá que migrar manualmente los proyectos portlet a Portal Tools de
Rational Application Developer V6.0, de la siguiente manera:
- Exporte el proyecto existente a un archivo WAR: En la versión
anterior de Portal Toolkit, exporte cada proyecto a un archivo WAR con los
archivos fuente.
- Pulse el proyecto con el botón derecho del ratón y seleccione
Exportar.
- Seleccione Archivo WAR y Exportar archivos fuente y
pulse Finalizar.
- Importe el archivo WAR del portlet:
- En Portal Tools para Rational Application Developer V6.0, cree un
nuevo proyecto portlet vacío.
- Seleccione Archivo -> Nuevo ->
Proyecto -> Portal -> Proyecto portlet
o proyecto portlet (JSR 168).
- Deseleccione Crear un portlet.
- Pulse Mostrar avanzadas.
- Si está importando un portlet WebSphere Portal 4.2, seleccione
2.2 como la versión de servlet.
- Seleccione WebSphere Portal v5.0 como el servidor
destino y pulse Finalizar.
- Importe el archivo WAR a este nuevo proyecto portlet vacío.
- Seleccione Importar.
- Seleccione Archivo WAR y especifique el archivo WAR que
exportó en un paso anterior (Exportar el proyecto a un archivo WAR de la
versión anterior).
- Seleccione el nuevo proyecto portlet vacío.
- Seleccione Sobrescribir recursos existentes sin avisar.
- No seleccione Suprimir proyecto al
sobrescribir.
- Suprima el archivo TLD:
Le recomendamos que suprima del proyecto el archivo TLD del portlet, si
existe. De lo contrario, recibiría un mensaje de aviso cuando
reconstruya el proyecto. Si lo deja, podría producirse un problema
cuando el proyecto portlet se despliegue en WebSphere Portal y el archivo TLD
del portlet sea distinto del archivo que hay en el servidor.
- Si está migrando un portlet WebSphere Portal 4.2, debe migrar
este proyecto de portlet migrado a WebSphere Portal 5.x.
La información sobre cómo migrar los portlets de WebSphere Portal
V4.2 a V5.x se encuentra en: Migrar los portlets de WebSphere Portal V4.2 a la V5.x.
Si desea información sobre cómo migrar los recursos Faces de un
proyecto portlet, consulte: Actualizar recursos de tiempo de ejecución de Faces en un proyecto de portlet.
Rational Application Developer V6.0 no soporta el desarrollo de
portlets de WebSphere Portal V4.2. Debe migrar los proyectos de
portlet de WebSphere Portal V4.2 a V5.x.
La mayoría de los portlets escritos para WebSphere Portal V4.2 se
ejecutarán sin cambios en WebSphere Portal V5.x. En la
versión 4.2.x, algunas de las API de portlet se han marcado
ahora como en desuso, pero siguen estando disponibles en WebSphere Portal
V5.x.
- Nota:
- Los proyectos de aplicación portlet migrados no son
retrocompatibles.
Para migrar las aplicaciones portlet de WebSphere Portal V4.2 a la
V5.x, siga estos pasos:
- Migre los proyectos portlet de Portal V4.2 a proyectos portlet de
Portal V5.x:
- Con el botón derecho del ratón, pulse el proyecto de la
aplicación portlet que desea migrar.
- Seleccione Propiedades -> API de Portlet para
abrir la página de las API de portlet.
- Seleccione WebSphere Portal Versión 5.x en la lista
desplegable en la que figuran los niveles de las API de portlet.
- Pulse Aceptar, y se producirán automáticamente los
siguientes cambios:
- Se elimina el archivo del descriptor de biblioteca de códigos (TLD) de
la API de portlet, si existe.
- El nivel Web pasa de 2.2 a 2.3.
- Se eliminan las entradas de vía de acceso de clases específicas del
portlet, porque el contenedor de JRE de WebSphere Portal y el contenedor del
destino de tiempo de ejecución de WebSphere Portal las añadirán
dinámicamente.
- Si el proyecto portlet está asociado a un proyecto de aplicación de
empresa, le recomendamos que migre el nivel J2EE del proyecto EAR a J2EE
1.3. Las aplicaciones portlet diseñadas para WebSphere Portal
V5.x deben estar en conformidad con las especificaciones J2EE de nivel
1.3.
- Nota:
- Antes de migrar el proyecto de aplicación de empresa a J2EE 1.3,
lea: Capítulo 4, Migrar proyectos J2EE. En la ayuda en línea encontrará información
sobre cómo utilizar el asistente de migración J2EE.
- Si el proyecto portlet migrado tan solo está asociado al proyecto de
aplicación de empresa, haga como se indica a continuación:
- Cierre todos los editores del entorno de trabajo.
- Con el botón derecho del ratón, pulse el proyecto de aplicación
de empresa al que está asociado el proyecto portlet migrado.
- Seleccione Migrar -> Asistente de migración
J2EE, y pulse Siguiente.
- Seleccione J2EE Versión 1.3 y WebSphere
Portal como servidor destino.
- Pulse Finalizar.
- Si hay otros proyectos portlet asociados al proyecto de aplicación de
empresa, debe eliminar el proyecto portlet migrado y añadirlo a otro
proyecto de aplicación de empresa.
- Elimine del proyecto de aplicación de empresa el módulo del proyecto
portlet migrado.
- Expanda el proyecto de aplicación de empresa y seleccione el descriptor
de despliegue.
- Seleccione Abrir con -> Editor de descriptores de
despliegue.
- Seleccione la pestaña Módulo. En el editor, en la
página Módulo, seleccione el archivo WAR del proyecto portlet
migrado.
- Pulse Eliminar.
- Seleccione Archivo -> Guardar para guardar los
cambios.
- Cree un nuevo proyecto de aplicación de empresa y añádale el
proyecto portlet.
- Seleccione Archivo -> Nuevo ->
Proyecto.
- Marque el recuadro de selección Mostrar todos los
asistentes.
- Expanda J2EE y seleccione Proyecto de aplicación de
empresa.
- Cumplimente el campo Nombre del proyecto, seleccione J2EE
Versión 1.3 y WebSphere Portal como servidor
destino, y pulse Siguiente.
- En la página Proyectos de módulo EAR, seleccione el
proyecto portlet migrado y pulse Finalizar.
Ahora, el proyecto portlet ya habrá migrado a WebSphere Portal
V5.x.
Los recursos de tiempo de ejecución de JavaServer Faces enviados
originalmente con WebSphere Studio Application Developer V5.1.2
se han actualizado para Rational Application Developer
V6.0.1. Si desea seguir desarrollando proyectos de
portlet creados con Portal Toolkit 5.0.2.2 para esta
versión anterior del producto, es recomendable que actualice los recursos
de tiempo de ejecución Faces a los últimos niveles.
En Rational Application Developer V6.0.1, las actualizaciones
de los recursos de tiempo de ejecución de Faces se producen
automáticamente cuando se importa un proyecto de portlet o se abre un
área de trabajo que contiene recursos no actualizados. Después de
importar un proyecto de portlet creado con Portal Toolkit
5.0.2.2 para WebSphere Studio Application Developer
V5.1.x a Rational Application Developer V6.0.1, se
le solicitará que actualice los recursos de tiempo de ejecución de Faces
a los últimos niveles.
Actualizar automáticamente recursos de tiempo de ejecución
Para actualizar automáticamente los recursos de tiempo de
ejecución de Faces para un proyecto de portlet:
- Importe un proyecto de portlet con contenido Faces de WebSphere Studio
Application Developer V5.1.x. Se abre la ventana
Migración de proyectos.
- Nota:
- Si la ventana Migración de proyectos no se abre, el valor de preferencia
de construcción automática esté probablemente inhabilitado. En
el Explorador de proyecto, pulse con el botón derecho del ratón sobre el
proyecto de portlet y seleccione Construir ->
Proyecto; el proceso de reconstrucción de un proyecto abre
la ventana Migración de proyectos.
- Si tiene otros proyectos de portlet con contenido de Faces en el área
de trabajo, marque Aplicar esta opción a cualesquiera otros proyectos
que necesiten actualizarse y se actualizarán todos los proyectos de
portlet.
- 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 de portlet o reiniciar el entorno de trabajo antes de reconstruir el
proyecto de portlet. Si ha inhabilitado las construcciones
automáticas, pulse con el botón derecho del ratón sobre el proyecto
de portlet 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.
- Para actualizar los recursos de tiempo de ejecución Faces
específicos del portlet, jsf-portlet.jar y jsf-wp.jar, debe
seguir los pasos de actualización manual que se indican a
continuación.
- Nota:
- Si ha creado JSP Faces que contenían componentes de cliente Faces, debe
actualizar por separado los recursos de tiempo de ejecución de componentes
de cliente Faces a los últimos niveles. Consulte Actualizar recursos de tiempo de ejecución de cliente Faces en un proyecto Web.
Actualizar manualmente recursos de tiempo de ejecución
Para actualizar manualmente los recursos de tiempo de
ejecución de Faces para un proyecto de portlet:
- Importe el proyecto portlet existente con el contenido Faces a un área
de trabajo de Rational Application Developer V6.0.1.
- Cree un nuevo proyecto portlet que se llame JSFP601, teniendo
seleccionada la opción Portlet Faces en la segunda
página. Este proyecto tan solo lo utilizará como origen de los
recursos de tiempo de ejecución más recientes; puede suprimirse una
vez realizada la actualización.
- En el explorador de proyectos, pulse el proyecto JSFP601 con el
botón derecho del ratón y seleccione Propiedades en el
menú.
- Pulse Características de proyecto Web, seleccione
Añadir infraestructura de cliente Faces para proyecto de portlet
y pulse Aceptar.
- 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:
- jsf-api.jar
- jsf-ibm.jar
- jsf-impl.jar
- jsf-portlet.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>
<variable-resolver>com.ibm.faces.application.WPPortletVariableResolver</variable-resolver>
<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
</application>
- Nota:
- Si el proyecto portlet utiliza la API JSR 168, especifique
com.ibm.faces.application.PortletVariableResolver,
en lugar de
com.ibm.faces.application.WPPortletVariableResolver.
- Por cada uno de los archivos JAR que suprimió, copie el archivo JAR que
tenga el mismo nombre en el directorio WebContent/WEB-INF/lib del proyecto
JSFP601 y péguelo en el proyecto original en la misma
ubicación. En algunas configuraciones no hará falta que todos
estos archivos JAR estén presentes en el proyecto; no copie un archivo
JAR determinado si no estaba en el proyecto original.
- Si el proyecto portlet utiliza la API de portlet de IBM o un componente de
enlace personal, copie el archivo jsf-wp.jar en el proyecto
original.
- Si copia el archivo odc-jsf.jar, copie asimismo el archivo
odc-jsf-portlet.jar.
- 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>
- Suprima el proyecto de portlet JSFP601.
En Rational Application Developer V6.0, los entornos de prueba de
WebSphere Application Server que venían con el producto han sufrido cambios
que los diferencian de los que venían con las ediciones anteriores de
WebSphere Studio Application Developer.
A continuación se proporciona un resumen de los cambios realizados en
los entornos de prueba de WebSphere Application Server en Rational Application
Developer V6.0:
- 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.
- Se ha añadido el entorno de prueba de WebSphere Portal para poder
probar los portales y las aplicaciones portelt.
La siguiente tabla muestra los niveles de los entornos de prueba de
WebSphere Application Server que venían con las distintas versiones de
WebSphere Studio Application Developer y Rational Application
Developer.
Tabla 2. Entornos de prueba de WebSphere Application Server en WebSphere Studio Application Developer y Rational Application Developer
| WebSphere Application Server V4.x AE
| WebSphere Application Server V5.x Base
| WebSphere Application Server Express 5.x
| WebSphere Application Server V5.x Portal
| WebSphere Application Server V6.0
|
WebSphere Studio Application Developer V5.1
| V4.0.6
| V5.0.2
| V5.0.2
| No aplicable
| No aplicable
|
WebSphere Studio Application Developer V5.1.1
| V4.0.7 + PQ78374
| V5.0.2 + PQ78374 + PQ78419, V5.1
| V5.0.2 y V5.1
| No aplicable
| No aplicable
|
WebSphere Studio Application Developer V5.1.2
| V4.0.7 + PQ78374
| V5.0.2 + PQ78374 + PQ78419, V5.1.0.3
| V5.0.2 y V5.1.0.3
| V5.0.2.3 Base + WebSphere Portal
V5.0.2.1
| No aplicable
|
Rational Application Developer V6.0
| No aplicable
| V5.0.x, V5.1.1
| V5.0.2 y V5.1.1
| V5.0.2.6 Base + WebSphere Portal
V5.0.2.2, V5.1.1 Base + WebSphere Portal
5.1
| V6.0
|
Copyright y avisos