Migrar desde WebSphere Studio "Classic" a IBM WebSphere
Studio Site Developer
Capítulo 1. Visión general de la Guía para la migración de WebSphere Application Server - Express
Capítulo 2. Migrar el servidor de producción
Capítulo 3. Migrar desde IBM WebSphere Studio Site Developer Versión 5.1
Capítulo 4. Migrar desde IBM WebSphere Studio Site Developer Versión 5 o Versión 5.0.1
Capítulo 5. Migrar desde IBM WebSphere Studio Site Developer Versión 4.0.x
Capítulo 6. Migrar desde WebSphere Studio "Classic" a IBM WebSphere Studio Site Developer
Capítulo 7. Migrar desde VisualAge para Java a IBM WebSphere Studio Site Developer
Capítulo 10. Ejemplos de migración
En esta versión de IBM(R) WebSphere(R)Application Server - Express Versión 5.1 , puede migrar código desde:
WebSphere Application Server - Express 5.1 se compone de WebSphere Application Server 5.1 y WebSphere Studio Site Developer 5.1.1. El primer capítulo describe la migración de la característica de servidor de WebSphere Application Server - Express. El resto de esta guía de migración está dedicado a la migración de código desde diversas versiones de WebSphere Studio Site Developer.
Nota importante referente a la migración del servidor:
La migración de la configuración del servidor sólo es significativa si administra el servidor mediante la Consola administrativa, generalmente en un entorno de producción. En esta modalidad de operación, la configuración del servidor y las aplicaciones desplegadas se almacenan en el directorio config del servidor. El proceso de migración migra automáticamente estos archivos de configuración y de aplicaciones. Por otra parte, si utiliza WebSphere Studio Site Developer para configurar y desplegar aplicaciones en el servidor remoto, no es necesario migrar los archivos de configuración del servidor. Esto se debe a que los archivos de configuración y de aplicaciones se conservan todos en el área de trabajo de Studio Site Developer. Studio Site Developer migrará el área de trabajo. A continuación, puede definir una instancia de nueva de un servidor WebSphere Application Server - Express 5.1 y continuar configurando y desplegando las aplicaciones desde Studio Site Developer.
Esta guía consta de los capítulos siguientes:
Migrar desde WebSphere Studio "Classic" a IBM WebSphere
Studio Site Developer
Puede hallar información sobre cómo utilizar WebSphere Application Server - Express en la Guía de iniciación y en la ayuda en línea. Consulte la Guía de instalación antes de instalar WebSphere Application Server - Express. Una vez instalado correctamente WebSphere Application Server - Express, lea la Guía de iniciación y complete las Guías de aprendizaje que se incluyen. Las guías de aprendizaje le servirán de introducción al entorno de trabajo, el proceso de desarrollo de Java(TM) y los servicios Web. Tras haber completado las guías de aprendizaje, lea esta guía para migrar los recursos de aplicación a WebSphere Application Server - Express.
Esta guía está disponible en las versiones HTML y PDF de Acrobat, en el directorio /readme. Ambas versiones contienen idéntica información. Puede abrir el archivo migrate.html en cualquier navegador Web. Para abrir el archivo migrate.pdf, debe tener instalado el software de Acrobat Reader, que puede bajarse desde el sitio Web www.adobe.com/products/acrobat/readstep2.html.
En toda esta Guía para la migración se utilizan los convenios de Windows(R). Por ejemplo, "Dir_instalación_WS\" en Windows es equivalente a "Dir_instalación_WS/" en Linux.
Para futuras actualizaciones de esta guía, consulte el sitio www.ibm.com/websphere/developer/zones/studio/transition.html.
La migración es una actividad que puede aprovechar los materiales existentes. Las tareas y herramientas de migración ayudan a actualizar el producto y sus prerrequisitos, reutilizar componentes de aplicación existentes cuando procede y transferir configuraciones administrativas de la versión anterior a la actual.
La migración de los productos WebSphere Application Server potencia el entorno y las aplicaciones actuales y los modifica para que sean compatibles con la versión actual del producto.
Las herramientas de migración de IBM WebSphere Application Server - Express, Versión 5.1 suministran funciones de migración del producto. Las herramientas de migración ofrecen soporte para la migración desde:
El asistente de instalación del producto detectará las versiones anteriores de IBM WebSphere Application Server - Express y le ofrecerá la posibilidad de ejecutar las herramientas de migración durante la instalación de la Versión 5.1. Para migrar desde IBM WebSphere Application Server Versión 3.5, debe ejecutar estas herramientas directamente.
Redbook (libro rojo) de migración
Migrating to WebSphere V5: An End-to-End Migration Guide está disponible en el sitio Web de Redbooks, en http://www.ibm.com/redbooks. Para localizar el Redbook, busque el número de documento SG24-6910-00. El Redbook proporciona una visión más amplia que la de este artículo, incluida información de planificación más detallada para la migración de aplicaciones y herramientas y ejemplos de WebSphere Studio Application Developer.
Migración desde la Versión 3.5: Trasladarse al modelo J2EE
Los usuarios de la versión V3.5.x que actualizan a la versión V5 se trasladan a una plataforma que se basa en las especificaciones J2EE. La tecnología J2EE separa claramente las fases de desarrollo y creación de aplicaciones de las de administración, despliegue y gestión de las mismas. La migración desde V3.5 implica cambios en las estructuras, el desarrollo y el despliegue de las aplicaciones.
Las herramientas de migración facilitan la transición de la Versión 3.5.x a la Versión 5 migrando las configuraciones del sistema y creando artefactos J2EE, que incluyen la correlación de cometidos de seguridad J2EE. Las herramientas de migración crean aplicaciones de empresa J2EE iniciales basadas en configuraciones de la Versión 3.5.x. Sin embargo, debido al cambio significativo que experimentan las estructuras de las aplicaciones, planifique cuidadosamente la prueba y el ajuste de las aplicaciones migradas, mediante las herramientas de desarrollo y despliegue, para determinar exactamente cómo funcionarán las aplicaciones en el entorno nuevo.
El modelo J2EE permite desarrollar aplicaciones independientemente de su entorno de despliegue final. Esta separación de tareas simplifica el proceso de promocionar una aplicación desde el desarrollo inicial hasta la producción, o el traslado de una aplicación de un servidor a otro. El objetivo consiste en cambiar sólo los parámetros de despliegue de la aplicación, y no el código de la misma.
Antes de empezar, determine si tiene instalada una versión existente de WebSphere Application Server en la máquina en la que tiene previsto instalar el producto de la Versión 5.1. Si tiene una versión anterior, debe planificar si debe copiarse la configuración y las aplicaciones de la versión anterior en la versión nueva, lo que implica una migración. La migración no desinstala la versión anterior. El release anterior sigue operativo. Si lo ejecuta al mismo tiempo que la instalación de la Versión 5.1, las dos versiones coexistirán. Para poder ejecutar ambas versiones simultáneamente, será necesario configurar los puertos de forma que no entren en conflicto. Tenga en cuenta que la operación de migración sólo migra las definiciones de puerto tal como están, de modo que las definiciones de puerto son las mismas en ambas versiones. WebSphere Application Server contiene herramientas de migración que proporcionan todas las funciones de migración. Puede llamar a las herramientas de migración mediante el asistente de instalación o hacerlo más tarde manualmente.
Desde un punto de vista general, la migración desde IBM WebSphere Application Server - Express V5.0.x a V5.1 es bastante rutinaria. Puede utilizar el instalador para realizar la migración, teniendo que realizar muy poco ajuste postmigración, o ninguno en absoluto. También puede utilizar las herramientas de migración manualmente para guardar los datos de configuración de las versiones V5.0.0, V5.0.1 o V5.0.2, desinstalar las versiones V5.0.0, V5.0.1 o V5.0.2, instalar V5.1 y utilizar de nuevo las herramientas de migración para restaurar los datos de configuración.
Desde un punto de vista general, la migración desde IBM WebSphere Application Server V3.5 a IBM WebSphere Application Server - Express V5.1 implica cambios significativos en las estructuras, el desarrollo y el despliegue de las aplicaciones. Las herramientas de migración facilitan esta transición migrando las configuraciones del sistema y creando artefactos J2EE, que incluyen la correlación de los cometidos de seguridad anteriores a los cometidos de seguridad de J2EE. Estas correlaciones de seguridad permiten acceder a los elementos migrados durante la transición. Las herramientas de migración crean aplicaciones de empresa J2EE iniciales basadas en configuraciones de la Versión 3.5.x. Sin embargo, debido a los cambios significativos que sufren las estructuras de las aplicaciones, compruebe y ajuste cuidadosamente las aplicaciones migradas mediante las herramientas de desarrollo y despliegue.
El proceso de migración guarda los siguientes archivos en el directorio backup .
Este tema presenta las herramientas de migración suministradas por WebSphere Application Server. Todas las herramientas de migración se suministran en el directorio /migration del CD-ROM del producto. Es importante utilizar las herramientas de migración correspondientes a la versión de Application Server que esté instalando. Las herramientas cambian de una versión a otra. Las herramientas del CD-ROM del producto proporcionan las funciones necesarias para la migración de un release anterior de Application Server al que figura en el CD-ROM del producto. Las herramientas del CD-ROM coinciden con el producto del CD-ROM. Si utiliza herramientas de migración de un release anterior de Application Server, probablemente se producirán problemas en la migración.
El script WASPreUpgrade.sh (o WASPreUpgrade.bat) es una herramienta de migración destinada a migrar la configuración y las aplicaciones de versiones o releases anteriores a la Versión 5.1 de Application Server - Express.
El archivo del mandato se encuentra en el subdirectorio AppServer/bin del directorio raíz de instalación después de la instalación. También está disponible directamente en el subdirectorio migration del CD.
Sintaxis
WASPreUpgrade directorioCopiaSeguridad directorioWASactual
[nombreNodoAdmin]
[-nameServiceHost nombre_sistema_principal [-nameServicePort número_puerto ]]
[-traceString espec_rastreo [-traceFile nombre_archivo ]]
Parámetros
Los dos primeros argumentos son obligatorios y posicionales.
Los argumentos soportados son:
Anotación
La herramienta WASPreUpgrade visualiza información de estado en la pantalla durante su ejecución. También guarda un conjunto más amplio de información de anotaciones en el directorio backup. Puede visualizar el archivo WASPreUpgrade.log con un editor de texto.
El script WASPostUpgrade.sh (o WASPostUpgrade.bat) es una herramienta de migración destinada a migrar la configuración y las aplicaciones de versiones o releases anteriores a la Versión 5.1 de Application Server - Express.
El archivo del mandato se encuentra en el directorio AppServer/bin del directorio raíz de instalación.
La herramienta WASPostUpgrade instala todas las aplicaciones migradas en el directorio AppServer/installedApps de la instalación de La Versión 5.1. La herramienta incluye las aplicaciones del directorio de copia de seguridad creado por la herramienta WASPreUpgrade. La herramienta WASPreUpgrade copia las aplicaciones del directorio installedApps y de otros directorios de la versión o release anterior.
Sintaxis
WASPostUpgrade directorioCopiaSeguridad
[-serverName nombre_servidor]
[-webModuleAdditionalClasspath vía_acceso_clases]
[-documentRootLimit número]
[-substitute "clave1=valor1[;clave2=valor2;[...]]"]
[-portBlock número_puerto_inicial]
[-backupConfig true | false]
[-replaceNodes true | false]
[[-traceString espec_rastreo [-traceFile nombre_archivo]]
Parámetros
El primer argumento es obligatorio. Los argumentos soportados son:
En el archivo de datos XML de entrada, cada clave aparece como $key$ para la sustitución. Este argumento sustituye cualquier aparición de $NODE_NAME$ por admin_node y de $APP_SERVER$ por default_server en el archivo XML de entrada.
Si la serie de sustitución contiene signos de punto y coma, utilice $semiColon$ para separarla del delimitador ";". En plataformas UNIX, añada un carácter de escape a cada signo de dólar ($) de la serie de sustitución (por ejemplo, \$semiColon\$).
Este parámetro es aplicable a las configuraciones guardadas desde Advanced Edition, Versión 3.5.x.
Anotación
La herramienta WASPostUpgrade visualiza información de estado en la pantalla durante su ejecución. También guarda un conjunto más amplio de información de anotaciones en el directorio logs Puede visualizar el archivo WASPostUpgrade.log con un editor de texto.
Este tema describe los elementos que cambian durante la migración, que siempre implica a una sola máquina, como por ejemplo un entorno de desarrollo de una máquina autónoma.
Analice el archivo WASPostUpgrade.log para obtener información detallada acerca de los beans de empresa migrados. El modelo de programación J2EE especifica una arquitectura para la creación y despliegue de las aplicaciones. Dado que las aplicaciones de la Versión 3.5.x no tienen la misma arquitectura, la herramienta WASPostUpgrade vuelve a crear las aplicaciones. Crea todos los recursos Web y beans de empresa migrados en aplicaciones J2EE. Correlaciona todas las aplicaciones de empresa de la instalación de la Versión 3.5.x con aplicaciones J2EE con el mismo nombre, desplegadas en el mismo servidor.
La herramienta WASPostUpgrade correlaciona los recursos Web que no están incluidos en una aplicación de empresa con una aplicación J2EE por omisión que incluye el nombre del servidor. La herramienta correlaciona las aplicaciones Web con archivos WAR J2EE. Combina los recursos en un archivo EAR J2EE y lo despliega en la configuración de la Versión 5.
Puede utilizar un archivo datasources.xml de la Versión 3.5.x para aumentar los valores de configuración de origen de datos. La Versión 3.5.x almacena el archivo en el directorio properties . Las herramientas de migración migran un archivo datasources.xml existente fusionando las propiedades del archivo con la configuración del controlador JDBC y el origen de datos.
Las entradas de aplicación de empresa de la Versión 3.5.x son opcionales, ya que la mayoría de las veces se utilizan para agrupar conjuntos de objetos para definiciones de seguridad. Las partes de bean de empresa y aplicación Web de la aplicación de empresa señalan a sus entradas respectivas de las otras partes del archivo xml. Cada aplicación de empresa se procesa para crear una aplicación J2EE con el mismo nombre. Las entradas de bean de empresa y aplicación Web se utilizan como punteros que indican las definiciones de beans de empresa y aplicaciones Web. A continuación, los detalles de estas entradas se utilizan para construir una aplicación J2EE.
Para archivos de bean de empresa, se utiliza la definición de archivo JAR para buscar los archivos JAR que deben volver a desplegarse y añadirse a la aplicación J2EE. Las entradas de raíz de documentos de aplicación Web se utilizan para buscar los recursos utilizados en la aplicación Web (HTML, páginas JSP, etc.). Estos archivos se copian en el archivo WAR de la aplicación J2EE. Las entradas de vía de acceso de clases de la aplicación Web se utilizan para buscar los servlets y archivos JAR que se copian en el archivo WAR de la aplicación J2EE.
Durante la migración desde la Versión 3.5.x se crean aplicaciones de empresa. Se crean como aplicaciones de empresa compatibles con J2EE 1.2 y contienen módulos a nivel de Servlet 2.2 y JSP 1.1. Esto proporciona la compatibilidad más directa y permite la interoperabilidad con versiones anteriores de WebSphere Application Server.
El modelo de autorización de seguridad de la versión 3.5.x se basa en el concepto de Aplicación de empresa y Grupos de métodos. El producto resultante de la combinación de la aplicación de empresa y los grupos de métodos es un permiso de WebSphere Application Server. La especificación J2EE incluye un modelo de autorización basado en cometidos.
Para convertir el modelo de permisos de la versión 3.5.x de WebSphere Application Server al modelo de autorización basado en cometidos de la Versión 5, las herramientas de migración crean una correlación de uno a uno desde un permiso de WebSphere Application Server a un cometido nuevo dentro de esa aplicación. Por tanto, para cada aplicación de empresa y cada grupo de métodos de la Versión 3.5.x, las herramientas de migración crean un cometido en la Versión 5, contenido en el descriptor de despliegue de aplicaciones J2EE. Los sujetos con autorización para cada uno de los cometidos se encuentran en una tabla de autorizaciones que se encuentra en el enlace de aplicación J2EE.
La especificación J2EE incluye un modelo de autorización basado en cometidos. WebSphere Application Server interpreta el cometido como un conjunto de permisos que permiten acceder a un recurso. En el caso de una invocación de método de bean de empresa, el permiso para acceder al método de un bean determinado se especifica mediante un permiso de método. Este permiso de método está asociado con uno o varios cometidos en el descriptor de despliegue del archivo JAR del bean.
En el caso del acceso a recursos Web, el permiso para acceder a un URI Web e invocar un método HTTP en dicho URI se especifica en términos de colecciones de recursos Web y restricciones de seguridad en la especificación J2EE. El descriptor de despliegue del archivo WAR de la aplicación Web contiene las restricciones de seguridad y las colecciones de recursos Web.
La Versión 5 ejecuta los objetos JSP 1.0 y 1.1 como objetos JSP 1.2, que es el único nivel soportado.
La Versión 5 no da soporte al redireccionador de servlets de versiones anteriores. Las herramientas de migración pasan por alto estos objetos.
Si la configuración de la Versión 3.5.x define el servlet SimpleFileServlet, el servlet no se migra. Las herramientas de migración establecen el atributo FileServingEnabled del archivo de módulo Web ibm-web-ext.xmi en true.
Si la configuración de la Versión 3.5 define el servlet InvokerServlet, el servlet no se migra. Las herramientas de migración establecen el atributo ServeServletsByClassnameEnabled del archivo de módulo Web ibm-web-ext.xml en true.
Si la configuración de la Versión 3.5.x define el servlet DefaultErrorReporter, el servlet se migra al archivo de módulo Web web.xml. La migración utiliza el paquete nuevo para establecer el nombre de la clase.
El tipo de transporte por omisión del Motor de servlets en la Versión 3.5.x es OSE (Motor de servlets abierto). Dado que la Versión 5 ya no da soporte al transporte OSE, las herramientas de migración correlacionan estos transportes con transportes HTTP, utilizando las mismas asignaciones de puerto. Debe añadir manualmente entradas de alias VirtualHost para cada puerto.
Las configuraciones administrativas pueden migrarse con el asistente de instalación o manualmente, como se describe en esta tarea. Si decide migrar manualmente, no marque el recuadro de selección de migración en el panel de migración del asistente de instalación.
Si utiliza una versión anterior de WebSphere Application Server, es posible que el administrador del sistema haya realizado el ajuste de diversos valores de las aplicaciones y del servidor para su entorno. Es importante tener una estrategia para migrar estos valores con el máximo de eficacia y el mínimo de pérdida.
Puede realizar una migración manual incremental llamando a las herramientas de migración varias veces, especificando cada vez un archivo de configuración diferente. Existen diversas razones para tener varios archivos de configuración. Cualquiera que sea, la migración de los archivos de configuración de uno en uno permite probar las aplicaciones incrementalmente antes de continuar con el archivo de configuración siguiente.
Antes de utilizar las herramientas de migración, consulte el documento Notas del release V5.x para conocer los arreglos que debe aplicar a las versiones anteriores. El proceso de aplicación de arreglos a una versión anterior podría aplicar también arreglos a archivos que desempeñan una función en la migración. Aplique los arreglos para asegurarse de que la migración de las configuraciones y aplicaciones sea lo más efectiva posible.
La migración manual proporciona un método de migración más incremental que la migración completa realizada por el asistente de instalación. IBM suministra un conjunto de herramientas de migración para migrar configuraciones administrativas al producto WebSphere Application Server - Express desde cualquier edición de V3.5.x o V5.0.x. El proceso global de migración consiste en realizar la copia de seguridad de la configuración actual y de los archivos necesarios con la herramienta de migración WASPreUpgrade, desinstalar el release anterior, instalar la Versión 5 del producto sin seleccionar la opción de migración automatizada y restaurar la configuración desde el release anterior con la herramienta de migración WASPostUpgrade.
Seleccione cualquiera de estos escenarios de migración para obtener información acerca de cómo migrar datos de configuración a un nodo básico WebSphere Application Server:
Puede utilizar las herramientas de migración para migrar datos de configuración de la Versión 3.5 de WebSphere Application Server a la Versión 5.1 de WebSphere Application Server - Express.
Generalmente, utilizará las herramientas de migración WASPreUpgrade y WASPostUpgrade de la versión V5.1 de WebSphere Application Server para actualizar desde V3.5 a V5.1 en la misma máquina. Si su caso implica migrar una configuración V3.5 de una máquina a WebSphere Application Server - Express V5.1 de otra máquina, utilice el procedimiento alternativo descrito en la sección Migrar V3.5.x a una máquina remota V5.1.
Este tema describe la utilización de las herramientas de migración de V5.1 para migrar:
La herramienta WASPreUpgrade guarda la configuración existente de V3.5 en un directorio de copia de seguridad específico de la migración (migration-specific-backup). La herramienta WASPostUpgrade utiliza este directorio para añadir los valores de la configuración antigua al entorno V5.1 nuevo.
Pasos de esta tarea
En este CD se encuentra el directorio migration/bin. Este directorio contiene un entorno especial que puede utilizarse para ejecutar la herramienta WASPreUpgrade sin instalar V5.1.
Guarde la configuración en el directorio migration-specific-backup:
WASPreUpgrade /usr/tmp/migration-specific-backup /usr/websphere/appserver nombreNodo
Compruebe que el servidor administrativo del entorno existente está en ejecución. La herramienta WASPreUpgrade proporciona información de estado a la pantalla y a los archivos de anotaciones del directorio migration-specific-backup . Los nombres de archivos de anotaciones ASCII empiezan por el texto WASPreUpgrade e incluyen una indicación de la hora.
La herramienta WASPreUpgrade guarda todos los archivos de los siguientes directorios en la configuración existente de V3.5.x en el directorio de copia de seguridad (backup):
La herramienta WASPreUpgrade guarda los archivos seleccionados del directorio /bin de V3.5.x. También exporta la configuración existente de Application Server desde el depósito de V3.5.x. La herramienta WASPreUpgrade llama a la función XMLConfig para exportar el depósito existente de V3.5 al archivo websphere_backup.xml del directorio migration-specific-backup.
Si se produce un error durante la ejecución de la herramienta WASPreUpgrade, puede que sea necesario aplicar arreglos a la instalación V3.5 para poder realizar satisfactoriamente el paso de exportación. Consulte la página de soporte de IBM para conocer los arreglos más actualizados que puede aplicar. Si visualiza esta documentación desde InfoCenter, pulse Support para enlazar con la página de soporte de IBM.
No seleccione la opción de migración, si aparece.
Después de cada utilización de WASPostUpgrade, compruebe los valores de puerto de V5 en dos archivos:
Si el puerto BOOTSTRAP_ADDRESS de la versión anterior es 900, la migración lo correlacionará con el puerto 7809. Si el puerto BOOTSTRAP_ADDRESS de la versión anterior no es 900, la migración correlacionará el valor con server1 en una migración Advanced Edition o con el nombre de servidor real en una migración Advanced Single Server Edition.
El proceso de WASPostUpgrade añade los puertos de Transporte HTTP de la versión anterior al archivo server.xml de la Versión 5. Esto significa que server1 contiene asignaciones de puerto de Transporte HTTP duplicadas, procedentes del panel de coexistencia y del Servidor por omisión de la versión anterior.
La herramienta WASPostUpgrade migra la información de configuración de V3.5.x creada por la herramienta WASPreUpgrade a la instalación V5.1. Dado que el producto V5.1 se ajusta al modelo de programación J2EE y V3.5.x no lo hace, es necesario realizar cambios significativos para aplicar la configuración de V3.5.x a la instalación V5.1.
La herramienta WASPostUpgrade no migra ejemplos ni la aplicación de consola administrativa, debido a que en V5.1 ya existen ejemplos y una aplicación de consola administrativa.
La herramienta WASPostUpgrade registra información detallada específica de cada bean de empresa que despliega en el archivo WASPostUpgrade.log.
Configurar WebSphere Application Server después de la migración es una forma de comprobar el resultado de las herramientas de migración. También puede utilizar la correlación de configuración durante la migración para comprobar el resultado de la misma. El tema dedicado a esta función contiene una descripción detallada acerca de cómo migran los objetos las herramientas de migración y lo que debe comprobarse.
Puede utilizar las herramientas de migración para realizar una migración manual entre dos máquinas.
Generalmente, utilizaría las herramientas de migración WASPreUpgrade y WASPostUpgrade de la versión V5.1 de WebSphere Application Server - Express para actualizar desde V3.5 a V5.1 en la misma máquina.
Sin embargo, en algunos casos es necesario migrar la configuración de V3.5 de una máquina a V5.1 en otra máquina. Uno de estos casos se produce cuando se instalan máquinas nuevas en el entorno V5.1 más actualizado, pero es necesario migrar la configuración de V3.5 existente en otras máquinas.
Este tema describe la utilización de las herramientas de migración de V5.1 para migrar:
La herramienta WASPreUpgrade guarda la configuración existente de V3.5 en un directorio de copia de seguridad específico de la migración (migration-specific-backup). La herramienta WASPostUpgrade utiliza este directorio para añadir los valores de la configuración antigua al entorno V5.1 nuevo.
Pasos de esta tarea
En este CD se encuentra el directorio migration/bin. Este directorio contiene un entorno especial que puede utilizarse para ejecutar la herramienta WASPreUpgrade sin instalar V5.1.
Guarde la configuración en el directorio migration-specific-backup de la máquina V3.5.
WASPreUpgrade /opt/tmp/migration-specific-backup /opt/websphere/appserver nombreNodoAdmin
Compruebe que el servidor administrativo del entorno existente está en ejecución.
La herramienta WASPreUpgrade proporciona información de estado a la pantalla y a los archivos de anotaciones del directorio /migration-specific-backup. Los nombres de archivos de anotaciones ASCII empiezan por el texto WASPreUpgrade e incluyen una indicación de la hora.
La herramienta WASPreUpgrade guarda los archivos seleccionados del directorio /bin de V3.5.x. También exporta la configuración existente de Application Server desde el depósito de V3.5.x. La herramienta WASPreUpgrade llama a la función XMLConfig para exportar el depósito existente de V3.5 al archivo websphere_backup.xml del directorio migration-specific-backup.
Si se produce un error durante la ejecución de la herramienta WASPreUpgrade, puede que sea necesario aplicar arreglos a la instalación V3.5 para poder realizar satisfactoriamente el paso de exportación. Consulte la página de soporte de IBM para conocer los arreglos más actualizados que puede aplicar. Si visualiza esta documentación desde InfoCenter, pulse Support para enlazar con la página de soporte de IBM.
Utilice ftp, almacenamiento compartido o algún otro mecanismo para copiar el archivo en la máquina nueva.
Realice las siguientes tareas en la máquina que tiene instalada la versión V5.1 de WebSphere Application Server - Express.
El archivo debe copiarse porque editará el archivo original en el paso siguiente.
Efectúe los siguientes cambios en el archivo:
Si utiliza el mismo nombre de nodo para la máquina V5.1 que el que ha utilizado para la configuración original V3.5, no lo cambie. Si no es así, debe cambiar todas las apariciones del nombre de nodo de V3.5 por el nombre de nodo que utilice para WebSphere Application Server V5.1. El nombre de nodo aparece en muchos fragmentos de código XML a lo largo del archivo. Si no cambia todas las apariciones, la migración de los datos será incompleta.
El archivo de configuración hace referencia a los nombres de vía de acceso en muchosd fragmentos de código XML a lo largo del archivo. Actualice las referencias efectuadas a archivos situados fuera de la estructura de directorios de V3.5 especificando el directorio equivalente de la máquina nueva, aunque sea necesario crearlo. La configuración de un entorno equivalente implica que puede ser necesario copiar el directorio original en la máquina V5.1. O puede ser necesario instalar el software adecuado.
Debe corregir las especificaciones de vía de acceso si son diferentes de las de la máquina que ejecuta V5.1. Por ejemplo, si efectúa la migración desde V3.5 en una plataforma Windows a V5.1 en una plataforma Linux, cambie las vías de acceso específicas de Windows del archivo de configuración por el estilo de vías de acceso de Linux. Cambie "c:\mystuff\somepath" por "/opt/mystuff/somepath".
Puede que sea necesario cambiar los ID de usuario y las contraseñas si no son idénticos a los utilizados en la máquina V5.1.
Para cambiar una contraseña codificada por una contraseña de texto plano, cambie <password>{xor}LCoxayht</password> por <password>mypassword</password>.
Puede que la configuración haga referencia a otras configuraciones o productos de software que no existen en la máquina nueva. Por ejemplo, puede que la máquina antigua tenga una base de datos. Posiblemente, la configuración de V5.1 deba seguir señalando a la base de datos de la máquina antigua. Modifique el origen de datos a fin de que señale a la base de datos de la máquina V3.5.
Utilice la herramienta WASPostUpgrade en el directorio AppServer/bin del directorio raíz de instalación de V5.1 para añadir la configuración de V3.5 a la configuración de V5.1.
WASPostUpgrade /opt/tmp/migration-specific-backup
La herramienta WASPostUpgrade registra información detallada específica de cada bean de empresa que despliega en el archivo /migration-specific-backup/WASPostUpgrade.log.
Puede utilizar el programa de instalación de V5.1 para migrar desde WebSphere Application Server - Express V5.0.x a V5.1.
Pasos de esta tarea:
Utilice el script stopServer.sh (o stopServer.bat) del directorio AppServer/bin del directorio raíz de instalación:
stopServer.sh server1
Puede migrar un nodo V5.0.x sin detenerlo. Sin embargo, no es necesario que el nodo esté en ejecución para migrar su configuración. Las herramientas de migración pueden recuperar todos los datos de configuración mientras en nodo está detenido. Y debe detener el nodo para poder iniciar el nodo V5.1 que está instalando. Por tanto, puede detener el nodo en este momento.
Seleccione la opción de migración, cuando aparezca.
Utilice la herramienta de primeros pasos (First Steps) cuando aparezca al final de la instalación del producto, o ejecute la prueba de la instalación por su cuenta, si por alguna razón no aparece la herramienta First Steps.
Puede desinstalar el servidor V5.0.x cuando sea necesario.
Puede utilizar las herramientas de migración para realizar una migración entre dos máquinas.
Antes de empezar
Generalmente, utilizaría las herramientas de migración WASPreUpgrade y WASPostUpgrade de la versión V5.1 de WebSphere Application Server para actualizar desde cualquier versión V5.0.x a V5.1 en la misma máquina.
Sin embargo, en algunos casos es necesario migrar la configuración de V5.0.x de una máquina a V5.1 en otra máquina. Uno de estos casos se produce cuando se instalan máquinas nuevas en el entorno V5.1 más actualizado, pero es necesario migrar la configuración de V5.0.x existente en otras máquinas.
Esta tarea describe la utilización de las herramientas de migración de V5.1 para realizar la migración.
La herramienta WASPreUpgrade guarda la configuración existente de V5.0.x en un directorio de copia de seguridad específico de la migración (migration-specific-backup). La herramienta WASPostUpgrade utiliza este directorio para añadir los valores de la configuración antigua al entorno V5.1 nuevo.
Pasos de esta tarea
En este CD se encuentra el directorio migration/bin. Este directorio contiene un entorno especial que puede utilizarse para ejecutar la herramienta WASPreUpgrade sin instalar V5.1.
Guarde la configuración en el directorio migration-specific-backup de la máquina V5.0.x.
WASPreUpgrade /opt/tmp/migration-specific-backup /opt/websphere/appserver
La herramienta WASPreUpgrade proporciona información de estado a la pantalla y a los archivos de anotaciones del directorio /migration-specific-backup. Los nombres de archivos de anotaciones ASCII empiezan por el texto "WASPreUpgrade" e incluyen una indicación de la hora.
Utilice ftp, almacenamiento compartido o algún otro mecanismo para copiar el archivo en la máquina nueva.
Utilice la herramienta WASPostUpgrade en el directorio AppServer/bin del directorio raíz de instalación de V5.1 para añadir la configuración de V5.0.x a la configuración de V5.1.
WASPostUpgrade /opt/tmp/migration-specific-backup
La herramienta WASPostUpgrade registra información detallada específica de cada bean de empresa que despliega en el archivo /migration-specific-backup/WASPostUpgrade.log.
Efectúe los siguientes cambios:
Puede que sea necesario cambiar los ID de usuario y las contraseñas si no son idénticos a los utilizados en la máquina V5.0.x.
Puede que la configuración haga referencia a otras configuraciones o productos de software que no existen en la máquina nueva. Por ejemplo, puede que la máquina antigua tenga una base de datos. Modifique el origen de datos a fin de que señale a la base de datos de la máquina antigua.
Puede migrar una versión anterior de un release de WebSphere Application Server Versión 3.5.x o Versión 5.0.x que se ejecute en un sistema operativo no soportado en la Versión 5.1.
Pasos de esta tarea
Existen dos opciones. Puede ejecutar el mandato desde el directorio migration\bin (o migration/bin) de raíz_plataforma del CD-ROM de la Versión 5.1. O puede copiar los archivos del directorio del CD-ROM en un directorio que creará en la unidad de disco.
Identifique el release de la Versión 3.5.x o 5.0.x y un directorio de copia de seguridad en el que el mandato almacenará los archivos de configuración y las aplicaciones migradas desde la versión anterior. Consulte el tema relativo a WASPreUpgrade para conocer la sintaxis del mandato.
Identifique el directorio de copia de seguridad y la ubicación de los archivos de configuración.
Unidad_CD:\WASPreUpgrade directorioCopiaSeguridad filepath\WebSphere\AppServer nombreNodo
Si esto funciona, vaya al Paso 4. Si por alguna razón no funciona, siga los pasos 2B a 2F.
Cambie las siguientes variables:
Identifique el directorio de copia de seguridad y la ubicación de los archivos de configuración.
suDirectorioDeMigración\WASPreUpgrade directorioCopiaSeguridad filepath\WebSphere\AppServer nombreNodo
Si es posible, conserve el mismo nombre de sistema y contraseñas que en el sistema antiguo. Coloque los archivos de base de datos relacionados con las aplicaciones que migra en la misma vía de acceso que en el sistema anterior. En general, intente conservar intactas las vías de acceso. Sin embargo, no instale la Versión 5.1 en el mismo directorio que la versión anterior. Si cambia las vías de acceso y los nombres, puede editar los archivos de configuración XML para que reflejen los cambios. Efectúe dichos cambios antes de ejecutar el mandato WASPostUpgrade que se indica más delante.
Especifique el directorio de copia de seguridad (y los nombres de los archivos de configuración no estándar del directorio) que ha creado el mandato WASPreUpgrade. Consulte el tema relativo a WASPostUpgrade para conocer la sintaxis del mandato.
raíz_instalación\bin\WASPostUpgrade WAS_HOME\migration
Este capítulo aborda los siguientes temas de migración:
En IBM WebSphere Studio Site Developer Versión 5.1.1 se ha añadido una función de direccionamiento de servidor. Por omisión, esta función está inhabilitada y debe habilitarla en la página de preferencias de J2EE seleccionando Ventana > Preferencias > J2EE. Los detalles de funcionamiento de la función de direccionamiento de servidor se encuentran en la información del producto IBM WebSphere Studio Site Developer. Cuando la función está habilitada, puede dirigirse a un servidor de aplicaciones determinado. Esta característica se ha implementado para dar soporte a JDK 1.4, que es el JRE de WebSphere Application Server Versión 5.1 que se suministra con IBM WebSphere Studio Site Developer Versión 5.1.1. Los proyectos J2EE que aprovechan el soporte de direccionamiento de servidor no son compatibles con versiones anteriores de IBM WebSphere Studio Site Developer y, por tanto, no pueden compartirse con usuarios que trabajen en versiones anteriores de IBM WebSphere Studio Site Developer (por ejemplo, IBM WebSphere Studio Site Developer Versión 5.1, IBM WebSphere Studio Site Developer Versión 5.0.1). IBM WebSphere Studio Site Developerproporciona una forma de obtener compatibilidad con versiones anteriores teniendo habilitada esta característica, que se describe en la sección "Compatibilidad con versiones anteriores con el soporte de direccionamiento de servidor habilitado". La razón de esta incompatibilidad es que la función de direccionamiento de servidor cambia el archivo .classpath en un proyecto J2EE y las versiones anteriores de WebSphere Application Server - Express no pueden reconocer las nuevas entradas del archivo .classpath.
Con el soporte de direccionamiento de servidor habilitado, los proyectos J2EE direccionados a un servidor pueden volver a no utilizar el soporte de direccionamiento de servidor modificando el servidor destino con la opción No se ha especificado un servidor destino disponible en el diálogo Modificar servidor destino. El diálogo Modificar servidor destino se abre desde el menú emergente (Servidor destino > Modificar) de un proyecto J2EE en la vista Navegador de recursos o en la perspectiva J2EE. El servidor destino también puede modificarse indicando No se ha especificado ningún servidor destino en la página de propiedades de J2EE (Propiedades > J2EE) para proyectos EAR, EJB, de Cliente de aplicaciones y de Conector. En el caso de un proyecto Web, el valor de servidor destino se encuentra en la página de propiedades Web (Propiedades > WEB). Los detalles de funcionamiento de la función de modificación de direccionamiento de servidor se encuentran en la información del producto IBM WebSphere Studio Site Developer. Cuando se utiliza la opción No se ha especificado un servidor destino, el archivo .classpath vuelve al estilo compatible con versiones anteriores de IBM WebSphere Studio Site Developer y el archivo .server se elimina del proyecto.
Debido a un cambio en JDK 1.4, el usuario debe especificar un paquete Java al utilizar los asistentes Páginas Web de base de datos y Páginas Web de bean Java para generar páginas que deben ejecutarse en IBM WebSphere Studio Site Developer Versión 5.1.1. Este problema se produce si se utiliza la plantilla Bean de vista para el asistente Páginas Web de bean Java o IBM Database Access Java Beans-Master Details Pattern. También se aplica a los proyectos que contienen páginas y archivos .java generados anteriormente con estos asistentes sin especificar un paquete durante la creación. Para acceder al código generado anteriormente, mueva los archivos .java a un paquete. A continuación, actualice los archivos .jsp, los sentencias de importación y la información de clases. En el archivo web.xml del proyecto, actualice la entrada servlet-class.
Este capítulo aborda los siguientes temas de migración:
IBM WebSphere Studio Site Developer Versión 5.1.1 se basa en la nueva versión básica de Eclipse WebSphere Studio Workbench (WSWB) 2.1.2. Existen algunas diferencias entre las versiones 2.1.2 y 2.0.3 o 2.0.2. Para obtener información detallada acerca de estas diferencias, consulte el archivo readme que se encuentra en el directorio dirinstal_WS\eclipse\readme (donde dirinstal_WS es la vía de acceso en la que ha instalado IBM WebSphere Studio Site Developer .
IBM WebSphere Studio Site Developer Versión 5.0 se basaba en la versión básica de Eclipse WSWB 2.0.2 y IBM WebSphere Studio Site Developer Versión 5.0.1 se basaba en la versión básica de Eclipse WSWB 2.0.3. No existen grandes diferencias entre las versiones 2.0.2 y 2.0.3. El release de IBM WebSphere Studio Site Developer Versión 5.0.1 era un paquete de arreglos del Gestor de actualizaciones que se instalaba encima de IBM WebSphere Studio Site Developer Versión 5.0.
Cuando se inicia IBM WebSphere Studio Site Developer Versión 5.1.1 por primera vez mediante un área de trabajo existente de IBM WebSphere Studio Site Developer Versión 5.0, aparece un recuadro de diálogo que muestra una forma de migrar desde la Versión 5.0. Pulse Aceptar para migrar el área de trabajo de la Versión 5.0 o pulse Cancelar para detener el inicio de IBM WebSphere Studio Site Developer .
Una vez migrada el área de trabajo, podrá seguir utilizándola con la Versión 5.0, ya que los metadatos de las características del proyecto nuevo se pasan por alto y pueden leerse con la Versión 5.0. No puede realizar cambios en la Versión 5.0 de los proyectos del área de trabajo que podrían afectar a los metadatos ni sobreescribir los metadatos de la nueva característica de proyecto de los proyectos.
Migrar proyectos Java desde la Versión 5 o la Versión 5.0.1 es muy sencillo y se realiza automáticamente. Una vez que los proyectos se han cargado en el área de trabajo de la Versión 5.1.1, no se producen cambios de metadatos en los archivos .classpath o .project, a menos que intente utilizar alguna de las características nuevas disponibles en la Versión 5.1.1.
Es necesario tener un cuidado especial cuando los desarrolladores cargan y operan sobre un proyecto de un depósito de equipo mediante IBM WebSphere Studio Site Developer Versión 5 y IBM WebSphere Studio Site Developer Versión 5.1.1. El problema general consiste en que la existencia, contenido e interpretación de los archivos de metadatos de las áreas de trabajo pueden ser específicos de una versión determinada de una característica o conector, y pueden ser diferentes entre las versiones. Las garantías de compatibilidad entre áreas de trabajo sólo cubren aquellos casos en los que todos los desarrolladores actualizan sus áreas de trabajo de IBM WebSphere Studio Site Developer en el paso de bloqueo. En tales casos, no debe existir ningún problema con los metadatos compartidos. Sin embargo, si algunos desarrolladores están trabajando en IBM WebSphere Studio Site Developer Versión 5.1.1 mientras que otros lo hacen en IBM WebSphere Studio Site Developer Versión 5, tales garantías no existen. Esta sección ofrece consejos sobre lo que debe y no debe hacerse.
La modalidad de anomalía habitual es observada por el usuario de IBM WebSphere Studio Site Developer Versión 5.1.1. Los metadatos de la Versión 5.1.1 se pierden cuando un usuario de la Versión 5 guarda los cambios y, a continuación, compromete los archivos de metadatos actualizados al depósito. Estas son las acciones que conducen a un resultado erróneo:
A continuación figura una lista de los elementos que deben tenerse en cuenta si el proyecto debe compartirse entre usuarios de IBM WebSphere Studio Site Developer Versión 5.1.1 y Versión 5 o Versión 5.0.1:
Este soporte se añadió en IBM WebSphere Studio Site Developer Versión 5.1.1. La información relativa a los recursos enlazados se registra en el archivo .project.
Recomendación: No los utilice. Mejor aún, inhabilite los recursos enlazados por medio de la página de preferencias Entorno de trabajo > Recursos enlazados.
La información relativa al constructor de herramientas externas se registra en el archivo .project. El formato de la información ha cambiado de la Versión 5 a la Versión 5.1.1. Los constructores creados o cambiados en la Versión 5.1.1 utilizan el formato nuevo, que no se interpreta en las áreas de trabajo de la Versión 5. Los constructores creados en la Versión 5 utilizan el formato antiguo y siguen funcionando en la Versión 5.1.1.
Recomendación: Cree o edite siempre los constructores de herramientas externas desde un área de trabajo de la Versión 5.
Este soporte se ha añadido. Esta información se registra en el archivo .classpath.
Recomendación: No especifique patrones de exclusión. Mejor aún, inhabilite los patrones de exclusión por medio de la página de preferencias Java > Compilador > Vía de acceso de construcción.
Este soporte se ha añadido. Esta información se registra en el archivo .classpath.
Recomendación: No especifique nada aparte de la carpeta de salida por omisión (a nivel de proyecto). Mejor aún, inhabilite las ubicaciones de salida múltiples por medio de la página de preferencias Java > Compilador > Vía de acceso de construcción.
Al conectar un archivo ZIP fuente a una biblioteca JAR en la vía de acceso de construcción Java, el prefijo de la vía de acceso raíz de código fuente se infiere automáticamente. Esto ha cambiado con respecto a la Versión 5, en la que podía establecerse explícitamente por medio de la interfaz de usuario y registrarse explícitamente en el archivo .classpath. En consecuencia, puede que un proyecto Java creado en un área de trabajo de la versión 5.1.1 no encuentre el código fuente conectado.
Utilice la Versión 5 para especificar la vía de acceso raíz de conexión de código fuente. En la Versión 5.1.1 se ofrece flexibilidad adicional para la conexión de código fuente. Puede suministrar una carpeta en lugar de un archivo JAR o ZIP como conexión de código fuente, y conectar código fuente a una carpeta de archivo de clase; esta función no está disponible en la Versión 5 (en la que la información de la Versión 5.1.1 se pasa por alto).
Se ha añadido la utilización de contenedores de vía de acceso de clases por parte del PDE. Los contenedores de vía de acceso de clases se registran en el archivo .classpath. Si se utilizan contenedores de vía de acceso de clases de PDE, un área de trabajo de la Versión 5 tendrá entradas de vía de acceso de clases no resueltas y, por tanto, la mayoría de las posibilidades Java (incluyendo las de compilación, búsqueda, ejecución y depuración) no producirán los resultados esperados.
Recomendación: Asegúrese de que el valor de la página de preferencias Desarrollo de conectores > Control de vía de acceso de construcción Java destinada a la utilización de contenedores de vía de acceso de clases está inhabilitada antes de crear ningún proyecto de conector (o de fragmento).
Los nombres de carpeta son Java Source y Web Content. Los nombres de carpeta por omisión para los proyectos Web nuevos pueden configurarse a través de una página de preferencias (Ventana > Preferencias > Herramientas Web > Proyecto nuevo). Los nombres por omisión son ahora JavaSource y WebContent. Estos nombres por omisión sólo se utilizarán para los nuevos proyectos Web. Los proyectos Web creados en versiones anteriores a este release seguirán funcionando con los nombres antiguos. En los proyectos Web estáticos ocurre lo mismo.
Si opta por cambiar los nombres de las carpetas de código fuente para los proyectos de 4.0.x y 5.0 en la Versión 5.1.1, utilice la acción de menú emergente Redenominar de la vista Navegador. La acción de menú emergente Redenominar permite redenominar los nombres de carpeta y fija la vía de acceso de construcción Java para los proyectos Web 4.0.x y 5.0.x.
En el caso de la carpeta JavaSource, la acción de menú emergente Redenominar funciona en las vistas Navegador de proyectos y Paquetes. En el caso de la carpeta WebContent, la acción de menú Redenominar funciona en la vista Navegador de recursos y Navegador de proyectos.
Si se guarda un proyecto Web de una versión anterior a este release en un depósito de SCM y después se carga en este release, mantendrá la estructura antigua con las carpetas source y webApplication. Ambas estructuras podrán construirse correctamente.
El entorno de ejecución de las herramientas Struts ha subido de la Versión 1.1 Beta 2 de La Versión 5 a la Versión 1.1. En IBM WebSphere Studio Site Developer Versión 5 (Disponibilidad general), al crear un proyecto Web tiene la opción de añadir soporte de Struts al proyecto. Puede optar por utilizar Struts 1.0.2 o Struts 1.1 Beta 2. En IBM WebSphere Studio Site Developer Versión 5.1.1, la segunda de estas opciones se ha sustituido por Struts 1.1. Si ha creado proyectos Web de Struts 1.1 Beta 2 en IBM WebSphere Studio Site Developer Versión 5, puede que desee convertirlos a Struts 1.1, pero no es necesario, ya que Struts 1.1 Beta 2 sigue estando soportado. Si tiene proyectos Web de Struts 1.1 Beta 2 que desee convertir a Struts 1.1, deberá hacer lo siguiente:
Toda esta información también es aplicable si mueve un proyecto Web de Struts 1.1 Beta 3 de IBM WebSphere Studio Site Developer Versión 5.0.1 a Struts 1.1.
Las herramientas de servicios Web han añadido dos nuevos protocolos de tiempo de ejecución de IBM WebSphere Application Server Versión 5.0.2 que sólo funcionan en WebSphere Application Server Versión 5.0.2. La migración no es obligatoria, ya que tanto IBM WebSphere Studio Site Developer Versión 5.1.1 como Websphere Application Server Versión 5.0.2 soportarán los protocolos de tiempo de ejecución nuevos y antiguos. IBM WebSphere Studio Site Developer generará y desplegará tres protocolos de tiempo de ejecución de artefactos de servicio Web: el protocolo de tiempo de ejecución antiguo "IBM SOAP", que funciona en WebSphere Application Server Versión 4.x y Versión 5.x; el protocolo de tiempo de ejecución nuevo "IBM WebSphere 5.0.2 runtime", que sólo funciona en WebSphere Application Server Versión 5.0.2; y el protocolo de tiempo de ejecución nuevo "Apache Axis 1.0", que sólo funciona en WebSphere Application Server Versión 5.0.2.
Los usuarios podrán reutilizar sin cambios sus proyectos de la Versión 5 y los servicios Web relacionados con archivos EAR y WAR en la Versión 5.1.1. Para poder convertir sus clientes y servicios Web al nuevo protocolo de tiempo de ejecución de IBM WebSphere 5.0.2 y sacar provecho de los estándares JSR 101, 109, WS-I y WS-Security, los usuarios deberán realizar una regeneración mediante el asistente de servicios Web. El explorador de servicios Web continuará leyendo automáticamente los favoritos del usuario, aunque el archivo físico de datos se trasladará automáticamente a una ubicación nueva.
Al migrar un área de trabajo de la Versión 5, recibirá un mensaje de error emergente que indica que "Se han producido problemas al restaurar el entorno de trabajo". Este mensaje aparece si la perspectiva Perfilado está abierta en el momento de efectuar la migración y si las vistas Almacenamiento dinámico o Estadísticas de instancia estaban visibles en le perspectiva Perfilado. Esto se debe a que las vistas Almacenamiento dinámico y Estadísticas de instancia que existían en la Versión 5 se han eliminado. Este mensaje también aparece si la perspectiva Perfilado está abierta en el área de trabajo en el momento de efectuar la migración. El mensaje de error puede pasarse por alto sin problemas pulsando Aceptar.
Para poder utilizar una plantilla personalizada creada en la Versión 5, debe cargar la plantilla personalizada, volver a conectarla a la base de datos y guardarla. La próxima vez que vuelva a cargar la plantilla personalizada guardada, se verificará la conexión.
Es posible que los artefactos J2EE 1.2 generados creados en este release no puedan leerse en IBM WebSphere Studio Site Developer Versión 4.0.3 ni ejecutarse en los entornos de prueba de la Versión 4.0.3. Dado que en la Versión 4.0.3 no se suministraba el asistente de plantillas, no se conserva la compatibilidad hacia atrás con dicha versión.
Las aplicaciones de plantilla generadas en este release pueden ejecutarse en la Versión 5 si, en las preferencias de proyecto Web, el nombre de la carpeta de código fuente Java se cambia por "Java Source" y el de la carpeta de contenido Web se cambia por "Web Content".
Este capítulo describe la migración desde IBM WebSphere Studio Site Developer Versión 4.0.x a la Versión 5.
Hay dos métodos soportados que puede utilizar para migrar los proyectos desde IBM WebSphere Studio Site Developer Versión 4.0.x a la Versión 5. Cada uno de estos métodos se describe a continuación con más detalle:
Tenga en cuenta que migrar de la Versión 4 a la Versión 5 no implica cambiar automáticamente el nivel del proyecto J2EE, puesto que la Versión 5 sigue pudiendo construir y generar en WebSphere Application Server Versión 4. Todos los tipos de proyectos J2EE, incluidos los proyectos Web, pueden migrarse utilizando el asistente de migración J2EE disponible en IBM WebSphere Studio Site Developer. Para acceder al asistente de migración J2EE, pulse con el botón derecho del ratón sobre un proyecto de tipo J2EE y seleccione Migrar > Asistente de migración J2EE.
A continuación se proporciona una lista parcial de las mejoras realizadas desde la Versión 4.0.x:
WebSphere InfoCenter [www.ibm.com/software/webservers/appserv/doc/v40/aes/infocenter/index.html] contiene la siguiente información:
El manual Migrating to WebSphere V5.0 An End-to-End Migration Guide es un buen recurso informativo para la migración desde la Versión 3.5 y la Versión 4.0 a la Versión 5 [www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246910.pdf].
La página de transferencia de archivos de WebSphere Application Server [www14.software.ibm.com/webapp/download/product.jsp?s=p&id=TDUN-49EVRT&type=s&dt=DIAGNOSTIC+TOOL] contiene herramientas que facilitan la conversión de la aplicación:
Si los proyectos tienen dependencias circulares, la Versión 5 informa de un error de construcción. Puede ir a Ventana > Preferencias > Java > Compilador, seleccionar la pestaña Vía de acceso de construcción y quitar la marca del recuadro de selección Detener construcción si se producen errores de vía de acceso de construcción. Tenga en cuenta que con esto ya no se detendrá la construcción, pero que se seguirán mostrando uno o varios errores de 'dependencia circular' en la vista Tareas (incluso aunque la construcción sea satisfactoria). En este caso, puede convertir estos errores en avisos seleccionando la pestaña Otros y, a continuación, cambiando la preferencia en el menú desplegable Dependencias circulares.
En IBM WebSphere Studio Site Developer Versión 5 se han producido cambios en la estructura interna de los proyectos con respecto a la Versión 4.0.3. Cuando se exporte un WAR Web J2EE 1.2 de la Versión 5 con código fuente Java, se importará en IBM WebSphere Studio Site Developer Versión 4 y la carpeta de código fuente se convertirá automáticamente al nombre correcto y se construirá adecuadamente. El proyecto Web se seguirá ejecutando correctamente en WebSphere Application Server Versión 4, de forma parecida a cuando un proyecto de la Versión 4 se importa en la Versión 5, debido a que la carpeta de código fuente se convierte automáticamente al nombre correcto. Para obtener más información acerca de los cambios de nombre de carpeta, consulte el apartado "Estructuras de proyectos Web de IBM WebSphere Studio Site Developer"
La estructura interna de los proyectos Web en IBM WebSphere Studio Site Developer Versión 5 difiere de la de IBM WebSphere Studio Site Developer Versión 4.0.x. Esta diferencia no radica en las diferencias entre J2EE 1.2 y J2EE 1.3, sino que responde más bien a un cambio en la utilización de la herramienta.
En la Versión 4, los proyectos Web eran proyectos Web dinámicos por omisión y aparecían en la vista Navegador con una carpeta source y una carpeta webApplication. En la Versión 5, si crea un proyecto Web dinámico, éste aparecerá con una carpeta Java Source en lugar de una carpeta source y una carpeta Web Content en lugar de una carpeta webApplication.
Sin embargo, si se guarda un proyecto Web de la Versión 4 en un depósito de SCM y después se carga en la Versión 5, mantendrá la estructura antigua con las carpetas source y webApplication. Ambas estructuras podrán construirse correctamente en la Versión 5.
En la Versión 5, puede crear proyectos Web tanto estáticos como dinámicos.
Los proyectos Web estáticos contienen sólo recursos estáticos como HTML, Java Scripts, imágenes, texto, etc., sin ningún contenido dinámico. Los proyectos Web estáticos pueden ejecutarse y servirse mediante un servidor Web HTTP tradicional, y no necesitan un servidor de aplicaciones Web.
Los proyectos Web dinámicos contienen recursos dinámicos J2EE como servlets, JSP, filtros y metadatos asociados, además de recursos estáticos. Al crear proyectos Web dinámicos, puede incluir hojas de estilo en cascada y bibliotecas de códigos JSP, para poder iniciar el desarrollo con un conjunto más variado de recursos de proyecto. Los proyectos Web dinámicos están siempre incluidos en proyectos de aplicación de empresa y sólo se ejecutan en servidores de aplicaciones Web.
Esta es la forma recomendada de mover áreas de trabajo de la Versión 4.0.x a IBM WebSphere Studio Site Developer Versión 5. Es el único método que migra toda la información, incluida la información de vía de acceso de construcción del proyecto.
Consejo: en la Versión 4, el directorio workspace estaba ubicado por omisión en el directorio de instalación. En la Versión 5, este valor por omisión ha cambiado a un directorio llamado workspace en el directorio Mis documentos. Si desea alterar temporalmente la ubicación en la que se almacena el trabajo, utilice la opción -data en el mandato al iniciar el entorno de trabajo.
Para ClearCase: utilice un área de trabajo en blanco de la Versión 5 y, para cada proyecto que desee cargar, seleccione Archivo > Importar > Proyecto ClearCase existente de WebSphere Studio 4.x en el área de trabajo.
Consideraciones posteriores a la migración:
El proyecto no se ha construido porque estaba involucrado en un ciclo o tenía problemas de vía de acceso. Falta la carpeta fuente necesaria: /MyHomePageExample403/source.
Los archivos de extensión de aplicaciones IBM EAR de la Versión 4 y los archivos de configuración del servidor contenían referencias de vías de acceso absolutas. Después de migrarlos en la Versión 5, debe abrirlos con el editor correspondiente (que cambiará automáticamente las referencias de vía de acceso absolutas por referencias relativas nuevas).
El archivo de extensiones de IBM contiene vías de acceso absolutas obsoletas. Esto puede corregirse automáticamente y debe guardarse. Con ello se eliminarán las vías de acceso del archivo, y sólo debe hacerse una vez. ¿Desea realizar una corrección automática?
Existen otros proveedores de SCM que suministran conectores SCM para IBM WebSphere Studio Site Developer. Puede examinar la lista de proveedores en www.ibm.com/software/ad/studioappdev/partners/scm.html. Como parte de su certificación Ready for IBM WebSphere Studio software [www.developer.ibm.com/websphere/ready.html], todos los proveedores de SCM que proporcionaron un conector de la Versión 4 se habrán asegurado de que los pasos de migración precedentes (guardar de la Versión 4 en el depósito SCM, cargar del depósito en la Versión 5) también funcionan para sus sistemas.
Este enfoque solo está parcialmente soportado y supondrá una migración incompleta. Se perderán todos los valores de la interfaz de usuario, de depuración y la mayoría de las preferencias. Los nombres de proyecto, los archivos fuente del proyecto y la vía de acceso de construcción Java (vía de acceso de clases) se mantienen, pero no se garantiza nada más. Este método solo debe utilizarse si no se está utilizando un sistema SCM soportado y si es de gran importancia conservar la información de la vía de acceso de clases de construcción del proyecto, la cual se pierde al importar proyectos exportados desde la Versión 4. Puede utilizar el área de trabajo existente de la Versión 4.0.x haciendo lo siguiente:
Las instrucciones para después de la migración descritas en el apartado Eliminación de las referencias de vía de acceso absolutas de EAR y Configuración del servidor posterior a la migración también son aplicables aquí.
Si intenta migrar abriendo un área de trabajo de la Versión 4.0 en IBM WebSphere Studio Site Developer Versión 5, pueden producirse los siguientes problemas.
Para restablecer la variable de vía de acceso de clases de JRE_LIB a una ubicación válida, siga estos pasos. Haga esto incluso aunque el valor parezca correcto la primera vez que abra la ventana Preferencias.
Si no lo hace, el valor de JRE_LIB podrá ser incorrecto, lo que causará muchos errores en los archivos Java.
Como comprobación general, verifique el valor del resto de variables de vía de acceso de clases.
El soporte de Equipo ha cambiado significativamente entre Eclipse 1.0 y 2.0. El método de compartimiento de productos con el depósito también ha cambiado.
Por omisión, los proyectos se crean en el directorio workspace. Si alteró el valor por omisión para crear proyectos en cualquier otra ubicación, debe abrir todos los proyectos ahora, antes de cerrar el entorno de trabajo. Esto permitirá que el archivo .project de ese proyecto se escriba en la ubicación adecuada. Si no se puede abrir un proyecto cerrado cuyo directorio esté fuera del área de trabajo, se obtendrá un proyecto que enmascara el proyecto real, en el que solo existe un archivo .project.
Deberá eliminar los puntos de interrupción JSP que tenga y volver a establecerlos en el área de trabajo migrada de la Versión 5.
Para migrar datos relacionales desde proyectos de IBM WebSphere Studio Site Developer 4.0.3:
Se restaurarán los artefactos de datos relacionales.
Si ha importado un archivo de servicios Web de 4.0.x, puede recibir los mensajes de error siguientes:
Error El componente 'result' tiene un valor no válido 'anyElement' definido para su tipo. Las declaraciones de tipo deben referirse a valores válidos definidos en un esquema. Error El componente 'return' tiene un valor no válido 'findPatientResult' definido para su elemento. Las declaraciones de elemento deben referirse a valores válidos definidos en un esquema. Error El componente 'response' tiene un valor no válido 'findPatientResponse' definido para su elemento. Las declaraciones de elemento deben referirse a valores válidos definidos en un esquema.
La solución consiste en lo siguiente:
Para acceder al asistente de migración de J2EE de la versión 5, siga estos pasos:
Este capítulo describe cómo migrar desde WebSphere Studio Versión 4.0 (ambas ediciones, Advanced y Professional) a IBM WebSphere Studio Site Developer . La migración desde WebSphere Studio "Classic" Versión 4.0 a IBM WebSphere Studio Site Developer Versión 5.0 implica los siguientes pasos:
La característica de publicación avanzada (correlacionar archivos con estadios de publicación) y la característica de detallador de páginas (análisis de páginas Web) de WebSphere Studio Classic no están disponibles en IBM WebSphere Studio Site Developer . Algunas otras características del paquete de CD de la Versión 4.0.x tampoco están disponibles. Por ejemplo, la característica Detallador de páginas para el análisis de páginas web, la característica HotMedia(R) para los tipos de soportes ricos, el Editor de voz XML (ha pasado a WebSphere Everyplace(TM) Toolkit y Portal Toolkit), DataBaseWizard para dispositivos de presencia generalizada.
Antes de migrar los datos de WebSphere Studio debería tener en cuenta las limitaciones siguientes:
Durante el proceso de migración que se describe a continuación, WebSphere Studio crea un archivo JAR que contiene todos los archivos del proyecto, publicables y fuente, para un solo servidor. Todos los archivos visibles en la vista Publicar del servidor por omisión se empaquetarán en el archivo JAR. A continuación, puede importar el archivo JAR en IBM WebSphere Studio Site Developer .
Cuando se migran proyectos existentes, toda la información de publicación y de etapas se pierde durante la migración. Si la etapa tiene varios servidores, solo se retendrán los archivos publicados en el servidor por omisión. Por lo tanto, a efectos de la migración, deberá crear una etapa que tenga solamente un servidor.
Si en la etapa actual tiene más de un servidor, cree una etapa nueva llamada Migración con un solo servidor; para ello, siga estos pasos:
El nombre por omisión del descriptor de la configuración Web es nombreServidor_web.xml, en este caso localhost_web.xml. A menos que haya especificado una ubicación distinta, el archivo .xml se guardará en el directorio WEB-INF.
Ahora ya está preparado para probar la aplicación. Para probarla en el servidor de prueba por omisión, siga estos pasos:
Para probar la aplicación en otros entornos de ejecución del servidor, consulte la ayuda en línea de la función Herramientas del servidor.
En este capítulo se dan instrucciones para migrar desde VisualAge(R) para Java Professional Edition o VisualAge para Java Enterprise Edition a IBM WebSphere Studio Site Developer.
Instantiations, Inc., Business Partner de IBM, distribuye un producto
llamado CodePro Studio que proporciona mejoras de productividad a VisualAge
para Java y WebSphere Application Server - Express incluyendo recursos para la
migración y la coexistencia. Para facilitar a los clientes de VisualAge
para Java el inicio del proceso de migración, Instantiations ofrece utilizar,
de forma gratuita e ilimitada, su servicio de exportación de VisualAge para
Java a IBM WebSphere Studio Site Developer, que forma parte de su copia de
evaluación por tiempo limitado de CodePro Studio. Puede bajar la copia
de evaluación del sitio Web www.instantiations.com/vaj-migrate.
Si quiere obtener más información sobre las funciones avanzadas de migración y
coexistencia de Instantiation, incluyendo la exportación e importación de
archivos completamente bidireccional, la creación de juegos de exportación e
importación, la sincronización de proyectos y la automatización de tareas,
visite el sitio Web http://www.instantiations.com/codepro/ws.
A continuación se ofrece una lista parcial de cambios que se han producido con respecto a VisualAge para Java:
Los pasos siguientes resumen el proceso de migración desde VisualAge para Java. Más adelante se detalla cómo llevar a cabo estos pasos:
La migración masiva de proyectos y recursos con versión desde el depósito de VisualAge para Java no está permitida. Solo puede migrar proyectos y recursos que estén en el área de trabajo de VisualAge para Java. Si quiere migrar una copia con versión de un proyecto o recurso a IBM WebSphere Studio Site Developer, deberá llevarla al área de trabajo de VisualAge para Java y después migrarla.
Exporte los proyectos a un archivo JAR siguiendo estos pasos:
Inicie IBM WebSphere Studio Site Developer y, a continuación, cree los proyectos adecuados. A continuación se dan unas directrices generales sobre migración que le ayudarán a decidir a qué tipo de proyecto de IBM WebSphere Studio Site Developer deberá importar los archivos:
Si la aplicación utiliza servlets, entonces tendrá que definir las correlaciones servlet-URL en el archivo web.xml. Siga estos pasos:
Deberá anotar los siguientes valores de VisualAge para Java y configurarlos en IBM WebSphere Studio Site Developer :
Vía de acceso de clases del proyecto
En VisualAge para Java, la vía de acceso de clases del proyecto se establece en las páginas de Recursos de la ventana Opciones (Ventana > Opciones > Recursos). Después de migrar los proyectos a IBM WebSphere Studio Site Developer , puede configurar la vía de acceso de clases del proyecto en la ventana Propiedades del proyecto (pulse el proyecto con con el botón derecho del ratón y seleccione Propiedades > Vía de acceso de construcción Java. Pulse la pestaña Bibliotecas). También puede establecer las variables de vía de acceso de clases en la ventana Preferencias (Ventana > Preferencias > Java > Variables de vía de acceso de clases).
Asociaciones de recursos
Si configura una asociación entre un tipo de archivo y un ejecutable, podrá abrir un archivo que esté fuera del entorno de trabajo desde dentro de él.
En VisualAge para Java, las asociaciones de recursos se configuran en la ventana Opciones (Ventana > Opciones > Recursos > Asociaciones de recursos). Después de migrar los archivos de recursos a IBM WebSphere Studio Site Developer , puede configurar las asociaciones de recursos mediante la ventana Preferencias (Ventana > Preferencias > Entorno de trabajo > Asociaciones de archivos).
Formateador de código
En VisualAge para Java, las opciones de formato de código se configuran en la página Formateador de la ventana Opciones (Ventana > Opciones > Codificación > Formateador). Después de migrar el código a IBM WebSphere Studio Site Developer , puede configurar el formato de código en la ventana Preferencias (Ventana > Preferencias > Java > Formateador de código).
Configuración de WTE
En VisualAge para Java, los valores de ejecución del Entorno de prueba de unidades de WebSphere y de WebSphere Application Server se encuentran en varios archivos de propiedades en estos directorios:dirInstalaciónVisualAge\ide\project_resources\IBM WebSphere Test Environment\properties, donde dirInstalaciónVisualAge es el directorio donde se ha instalado el producto.
Si, por ejemplo, se ha habilitado la reescritura de URL en el archivo de propiedades session.xml cambiando la propiedad por true de la forma siguiente: <url-rewriting-enabled>true</url-rewriting-enabled>, puede configurar esta propiedad en el Entorno de prueba de IBM WebSphere Studio Site Developer Versión 4.0. (En la perspectiva Servidores, abra la vista Configuración del servidor, pulse el botón derecho del ratón sobre el servidor con el que desea trabajar y pulse Abrir. Pulse la pestaña Web y ponga una marca en el recuadro de selección Habilitar reescritura de URL).
Archivos Java y archivos de recursos de proyecto
El archivo de propiedades default.servlet_engine contiene la raíz de contexto <root-uri> de las aplicaciones web de VisualAge para Java. Cuando se crea un proyecto Web en IBM WebSphere Studio Site Developer , el diálogo Crear un proyecto Web contiene un campo Raíz de contexto para estos datos.
Los valores de aplicación Web que estén en archivos como DirInstalVisualAge\ide\project_resources\IBM WebSphere Test Environment\hosts\default_host\default_app\servlets\default_app.webapp que haya personalizado usted mismo deben migrarse al archivo su_proyecto_Web\Web Content\WEB-INF\web.xml de IBM WebSphere Studio Site Developer. Por ejemplo, si ha cambiado los nombres de servlets y las vías de acceso a servlets del archivo default_app.webapp, tendrá que hacer los cambios correspondientes en el archivo web.xml.
Si la aplicación es un proyecto Java, para probarla utilice el soporte normal de IBM WebSphere Studio Site Developer para Ejecutar o Depurar proyectos Java.
Si la aplicación utiliza WebSphere Application Server , pruébela utilizando el servidor WebSphere Application Server incorporado. Esto exige crear e iniciar un servidor de prueba por omisión. Para un proyecto Web, pulse con el botón derecho del ratón en la página HTML principal y seleccione Ejecutar en servidor para iniciar el navegador web.
En la ayuda en línea puede obtener más información sobre cómo probar otros tipos de proyectos.
Si va a utilizar WebSphere Application Server como entorno de ejecución, despliegue la aplicación utilizando la función Herramientas del servidor de IBM WebSphere Studio Site Developer .
Los proyectos de IBM WebSphere Studio Site Developer (y los valores asociados) pueden compartirse entre desarrolladores. Para hacerlo, guarde un proyecto en el servidor de gestión de configuraciones de software (SCM) de IBM WebSphere Studio Site Developer y, a continuación, extráigalo en otro miembro del equipo en IBM WebSphere Studio Site Developer.
Para obtener información acerca del soporte de equipo en IBM WebSphere Studio Site Developer Versión 4.0, consulte el sitio www.ibm.com/websphere/developer/library/techarticles/0108_karasiuk/0108_karasiuk.html
En la Guía de instalación y en la ayuda en línea también puede hallar información acerca del soporte de equipo en IBM WebSphere Studio Site Developer.
Este capítulo proporciona instrucciones sobre cómo migrar las aplicaciones creadas en el Editor de composición visual de VisualAge para Java al Editor visual para Java de WebSphere Application Server - Express:
Este paso es opcional, pero es muy recomendable (especialmente si la aplicación tiene conexiones) por las razones siguientes:
Para guardar la información de metadatos mejorada antes de la migración:
Las clases están listas para importarse a WebSphere Application Server - Express. Consulte lo anterior en Capítulo 7, "Migrar desde VisualAge para Java a IBM WebSphere Studio Site Developer". Una vez que los programas fuente anteriores del Editor de composición visual se hayan importado en WebSphere Application Server - Express puede mantenerlos en el Editor visual para Java.
Este capítulo aborda los siguientes temas de migración:
Si desea obtener explicaciones detalladas, consulte el artículo acerca de J2EE Class Loading Demystified (www.ibm.com/websphere/developer/library/techarticles/0112_deboer/deboer.html) (J2EE modules and class paths) y acerca del desarrollo de JAR de utilidad de J2EE (www.ibm.com/websphere/developer/library/techarticles/0112_deboer/deboer2.html) (Java JARs in J2EE modules). Estos artículos proporcionan unos excelentes consejos y fundamentos técnicos.
La forma recomendada de utilizar un archivo JAR de terceros en un proyecto Web es importarlo (guardándolo como archivo JAR) a la carpeta library del proyecto Web. Esta es la única forma portable de utilizar un archivo JAR definida por J2EE, y garantiza que no habrá que hacer ningún cambio si se despliega en otro servidor.
Para utilizar un archivo JAR externo en un solo proyecto Web, siga los pasos que se indican a continuación. Si necesita utilizar el archivo JAR en varios proyectos Web, siga los pasos descritos en "Forma recomendada de utilizar un JAR de terceros para utilizarlo con varios proyectos Web" .
La forma recomendada de utilizar un archivo JAR de terceros con dos o más proyectos Web es importarlo (guardándolo como archivo JAR) al proyecto de aplicación de empresa (EAR). Esta es la única forma portable de utilizar un archivo JAR definida por J2EE, y garantiza que no habrá que hacer ningún cambio si se despliega en otro servidor.
Para utilizar un archivo JAR externo con varios proyectos Web, siga los pasos que se indican a continuación. Si solo necesita utilizar el archivo JAR en un único proyecto Web, siga los pasos del apartado anterior.
También puede dejar el archivo JAR fuera de WebSphere Application Server - Express y añadirlo tanto a la vía de acceso de construcción Java como a la vía de acceso de clases de la instancia del servidor. Esto no es recomendable porque la aplicación no será fácilmente portable. Si se traslada a otro servidor, siempre tendrá que actualizar la vía de acceso a clases del servidor. Además, debe asegurarse de que los archivos de clase no entren en conflicto con otras versiones de archivos de clase parecidos que ya estén en la vía de acceso de clases del servidor (y que necesite el servidor o el resto de aplicaciones). Si decide seguir este método, siga estos pasos:
La potente característica de autoconstrucción de WebSphere Application Server - Express puede ralentizar el rendimiento de la construcción durante construcciones multiproyecto complejas. Hay varias formas de controlar estas construcciones automáticas (archivos dependientes, proyectos activos e inactivos y proyectos en formato fuente o JAR) pero esas opciones pueden complicarse bastante. Hay un artículo que explica las opciones y cómo optimizar el rendimiento de la construcción. Consulte el artículo de WebSphere Developer Domain "Optimizing Multi-Project Builds Using dependent Project JARs in WebSphere Studio Application Developer" (www.ibm.com/websphere/developer/library/techarticles/0204_searle/searle.html).
Puede utilizar Ant con WebSphere Application Server - Express para automatizar las construcciones de producción. Existe un artículo de varios componentes que explica lo siguiente:
Consulte el artículo de WebSphere Developer Domain "Using Ant with WebSphere Studio Application Developer" (www.ibm.com/websphere/developer/library/techarticles/0203_searle/searle1.html).
Este capítulo contiene ejemplos de migración que le ayudarán a aprender más acerca de cómo migrar desde VisualAge para Java y WebSphere Studio "Classic" a WebSphere Application Server - Express IBM WebSphere Studio Site Developer.
Descripción
Este es el ejemplo FindTheLeapYears proporcionado con VisualAge para Java Versión 4.0. En la ayuda en línea de VisualAge para Java puede encontrar información sobre él (Ejemplos > Entorno de desarrollo JSP/Servlet).
Visión general sobre la migración
Siga los pasos indicados a continuación para migrar el ejemplo desde VisualAge para Java a IBM WebSphere Studio Site Developer. Estos pasos se describen en detalle más adelante:
Siga estos pasos para importar los archivos fuente Java al directorio "source" del proyecto LeapYear:
Importe los archivos de recursos al proyecto LeapYear del directorio WebContent siguiendo estos pasos:
Ahora necesitará hacer cambios a la aplicación a causa de las pequeñas modificaciones en la estructura de la aplicación y en el fuente.
En este punto, el ejemplo se ha migrado a IBM WebSphere Studio Site Developer. Todo lo que queda es crear un proyecto de servidor de IBM WebSphere Studio Site Developer y probar el ejemplo en el entorno de prueba de WebSphere.
Ahora tendrá que especificar el proyecto EAR para la configuración del servidor:
Descripción
En este ejemplo, deberá trabajar con WebSphere Studio "Classic" Versión 4.0.x.
El ejemplo con el que vamos a trabajar se denomina YourCo. Para acceder a este ejemplo, abra la ayuda en línea (Ayuda > WebSphere Studio 4.0 > Cómo > Trabajar con los ejemplos > Visión general). Para cargar este ejemplo, siga las instrucciones que se dan en Abrir los ejemplos de Studio (para WebSphere Application Server 4.0) y cargue YourCo.war.
Antes de empezar
Pasos para la migración
Para migrar este ejemplo desde WebSphere Studio "Classic" a IBM WebSphere Studio Site Developer, siga los pasos que se indican a continuación. Cada paso se describe detalladamente más adelante.
(Opcional) Normalmente, se creará una etapa nueva para una migración, pero en este ejemplo, utilizaremos la Etapa de prueba incluida con WebSphere Studio "Classic". Al utilizar la Etapa de prueba nos ahorraremos tener que editar manualmente muchas correlaciones de servlets en el paso 8.
Si desea obtener información acerca de cómo crear una etapa nueva para la migración, consulte el apartado "Migrar desde WebSphere Studio "Classic" a IBM WebSphere Studio Site Developer ".
a. com.ibm.db requiere databeans.jar, b. com.ibm.webtools.runtime requiere webtlsrn.jar, c. com.ibm.ejs.ns.jndi requiere ns.jar, d. com.ibm.webshpere.advanced.cm.factory requiere cm.jar, e. com.ibm.ejs.models.base.extensions.webappext.ServletExtensions requiere ws-base-extensions.jar
Para solucionar este problema, deberá modificar la vía de acceso de construcción Java del proyecto Web.
En este punto, el ejemplo se ha migrado a IBM WebSphere Studio Site Developer. Todo lo que queda es crear un proyecto de servidor de IBM WebSphere Studio Site Developer y probar el ejemplo en el entorno de prueba de WebSphere.
Ahora tendrá que especificar el proyecto EAR para la configuración del servidor:
Encontrará información actualizada acerca de la migración y de otros temas en el sitio Web www.ibm.com/websphere/developer/zones/studio/transition.html
Las publicaciones y las páginas Web siguientes proporcionan información general que puede serle útil cuando trabaje con WebSphere Application Server - Express:
Otras lecturas que pueden resultarle interesantes:
Nota sobre los derechos restringidos de los usuarios del Gobierno de EE. UU. - El uso, la reproducción o la divulgación están sujetos a las restricciones establecidas en el contrato GSA ADP Schedule Contract con IBM Corp.
Esta información ha sido desarrollada para productos y servicios que se ofrecen en EE.UU. Puede que IBM no ofrezca los productos, servicios o características descritos en este documento en otros países. Consulte al representante de IBM de su localidad si desea información acerca de los productos y servicios que están disponibles en su país. Las referencias hechas a productos, programas o servicios de IBM no pretenden afirmar ni dar a entender que únicamente puedan utilizarse dichos productos, programas o servicios de IBM. En su lugar se puede utilizar cualquier producto, programa o servicio funcionalmente equivalente que no vulnere los derechos de propiedad intelectual de IBM. Sin embargo, corresponde al usuario la responsabilidad de evaluar y verificar la operación de cualquier producto, programa o servicio que no sea IBM.
IBM puede tener patentes o patentes pendientes de aprobación que cubran alguno de los temas descritos en este documento. La posesión de este documento no le otorga ninguna licencia sobre dichas patentes. Puede enviar consultas sobre las licencias, por escrito, a:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
Estados Unidos
Para consultas sobre licencias relativas a la información de doble byte (DBCS), póngase en contacto con el departamento de propiedad intelectual de IBM en su país o envíe las consultas, por escrito, a:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japón
IBM puede utilizar o distribuir la información que se le suministre de la forma en que lo crea oportuna, sin que por ello incurra en ninguna obligación para con el remitente.
El párrafo siguiente no tiene aplicación en el Reino Unido ni en cualquier otro país en el que tales disposiciones sean incompatibles con la legislación local: INTERNATIONAL BUSINESS MACHINES CORPORATION PROPORCIONA ESTA PUBLICACIÓN "TAL CUAL" SIN GARANTÍA DE NINGUNA CLASE, EXPLÍCITA O IMPLÍCITA, INCLUYENDO, PERO SIN LIMITARSE A ELLAS, LAS GARANTÍAS O CONDICIONES IMPLÍCITAS DE NO VULNERABILIDAD, COMERCIALIZACIÓN O IDONEIDAD PARA UN PROPÓSITO DETERMINADO. Algunos estados no permiten la declaración de limitación de responsabilidad de las garantías implícitas en ciertas transacciones, y por tanto esta afirmación puede no aplicarse en su caso.
Esta información podría incluir imprecisiones técnicas o errores tipográficos. La información incluida en este documento está sujeta a cambios periódicos; estos cambios se incorporarán en nuevas ediciones de la publicación. IBM puede efectuar mejoras y/o cambios en los productos y/o programas descritos en esta publicación en cualquier momento sin previo aviso.
Los licenciatarios de este programa que deseen obtener información acerca del mismo con el fin de: (i) intercambiar la información entre programas creados independientemente y otros programas (incluido este) y (ii) utilizar mutuamente la información que se ha intercambiado, deben ponerse en contacto con:
Lab Director
IBM Canada Ltd. Laboratory
8200 Warden Avenue
Markham, Ontario, Canadá L6G 1C7
Dicha información puede estar disponible, sujeta a los términos y condiciones apropiados, incluyendo en algunos casos el pago de una cantidad.
IBM proporciona el programa bajo licencia descrito en este documento y todo el material con licencia disponible para el mismo bajo los términos del Acuerdo de cliente IBM, el Acuerdo internacional de licencia de programas IBM o cualquier acuerdo equivalente entre las dos partes.
La información concerniente a productos no IBM se ha obtenido de los suministradores de dichos productos, de sus anuncios publicados o de otras fuentes de información pública disponibles. IBM no ha comprobado dichos productos y no puede confirmar la exactitud en cuanto a rendimiento, compatibilidad u otras características relativas a productos no IBM. Las consultas acerca de las posibilidades de productos no IBM deben dirigirse a los suministradores de los mismos.
Las referencias hechas en esta publicación a sitios Web que no son de IBM se proporcionan únicamente por cortesía y de ningún modo deben interpretarse como un respaldo público de dichos sitios Web. Los materiales de estos sitios Web no forman parte de los materiales de IBM para este producto y el uso que se haga de estos sitios Web es de la entera responsabilidad del usuario.
Esta información contiene ejemplos de datos e informes utilizados en operaciones comerciales diarias. Para ilustrarlos lo más completamente posible, los ejemplos incluyen nombres de personas, empresas, marcas y productos. Todos estos nombres son ficticios y cualquier parecido con nombres y direcciones utilizados por una empresa real es pura coincidencia.
LICENCIA DE COPYRIGHT:
Esta información contiene programas de aplicación de ejemplo en lenguaje fuente, que muestran técnicas de programación en varias plataformas operativas. Puede copiar, modificar y distribuir estos programas de ejemplo de cualquier forma sin pagar nada a IBM, bajo el propósito de desarrollo, uso, márketing o distribución de programas de aplicación de acuerdo con la interfaz de programación de la aplicación para la plataforma operativa para la cual se han escrito los programas de ejemplo. Estos ejemplos no se han probado bajo todas las condiciones posibles. IBM, por lo tanto, no puede garantizar ni presuponer la fiabilidad, servicio o funcionalidad de estos programas. Puede copiar, modificar y distribuir estos programas de ejemplo de cualquier forma sin pagar nada a IBM bajo el propósito de desarrollo, uso, márketing o distribución de programas de aplicación de acuerdo con las interfaces de programación de aplicaciones de IBM.
Cada copia o parte de estos programas de ejemplo así como todo trabajo derivado, debe incluir un aviso de copyright como el siguiente:
(C) (nombre de su empresa) (año). Parte de este código procede de los programas de ejemplo de IBM Corp. (C) Copyright IBM Corp. 2000, 2003. Reservados todos los derechos.
La información de la interfaz de programación tiene como objetivo ayudarle a crear software de aplicación mediante este programa.
Las interfaces de programación genéricas le permiten escribir aplicaciones que obtienen los servicios de las herramientas de este programa.
Sin embargo, esta información también puede contener información de diagnóstico, modificación y ajuste. Se proporciona información de diagnóstico, modificación y ajuste para ayudarle a depurar el software de aplicación.
Aviso: esta información de diagnóstico, modificación y ajuste no debe utilizarse como interfaz de programación debido a que está sujeta a cambios.
Los términos siguientes son marcas registradas o marcas comerciales de International Business Machines Corporation en los Estados Unidos y/o en otros países:
Java y todas las marcas comerciales y logotipos basados en Java son marcas comerciales o marcas registradas de Sun Microsystems, Inc. en los Estados Unidos y en otros países.
ActiveX, Microsoft, Windows, Windows NT y el logotipo de Windows son marcas registradas o marcas comerciales de Microsoft Corporation en los Estados Unidos y/o en otros países.
UNIX es una marca registrada de The Open Group.
Otros nombres de compañías, productos o servicios, que pueden indicarse mediante un doble asterisco (**), pueden ser marcas registradas o marcas de servicio de otros.