Puede hacer varios cambios en aplicaciones y sus módulos sin tener que detener
el servidor ni reiniciarlo de nuevo. La realización de este tipo de cambios se conoce
como despliegue directo y recarga dinámica.
Antes de empezar
La nota siguiente se aplica a las referencias del archivo xmi en este tema:
Supported configurations: Para los
archivos de enlace y extensión de IBM®, la extensión
del nombre de archivo .xmi o .xml es diferente en función de si se utiliza una aplicación
o módulo previo a Java EE 5 o una aplicación o módulo
Java™ EE 5 o posterior. Un archivo de enlace o
extensión de IBM se denomina ibm-*-ext.xmi o
ibm-*-bnd.xmi donde * es el tipo de archivo de extensión o enlace como app, application,
ejb-jar o web. Se aplican las condiciones siguientes:
- En el caso de una aplicación o módulo que utilice una Java EE anterior a la versión 5, la extensión del archivo debe ser .xmi.
- En el caso de una aplicación que utilice Java EE versión 5 o posterior, la extensión del archivo debe ser .xml. Si los archivos .xmi se incluyen con la aplicación o el módulo, el producto ignora los archivos .xmi.
No obstante, puede existir un módulo de Java EE
5 o posterior dentro de una aplicación que incluya archivos previos a Java EE 5 y que
utilice la extensión de nombre de archivo .xmi.
Los archivos ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi,
y ibm-portlet-ext.xmi siguen utilizando la extensión de archivo .xmi.
sptcfg
![[Solaris]](../images/solaris.gif)
Restricción: No se da soporte a la función de despliegue directo y recarga dinámica cuando el producto se ejecuta en estos sistemas operativos. Se correlacionan los archivos archivadores Java (JAR) que aparecen dentro del Kit de desarrollo de Java (JDK) asociado. Si la función de despliegue directo y recarga dinámica actualiza estos archivos JAR cuando los utiliza la máquina virtual Java (JVM), los archivos dejan de ser coherentes, que da como resultado que el servidor de aplicaciones se bloquee. Cuando efectúe cambios en una aplicación en estos sistemas operativos, no utilice la función de despliegue directo y recarga dinámica.
En su lugar, reinicie la aplicación para que se reflejen los cambios.
En este tema se da por supuesto que los archivos de aplicaciones están desplegados en un servidor y que desea actualizar los archivos.
Consulte Formas de actualizar los archivos de aplicación empresariales y decida si el despliegue directo es el método adecuado para actualizar los archivos de la aplicación. Hay otros métodos más fáciles y el despliegue directo sólo es apropiado para usuarios experimentados.
No
utilice el despliegue directo si piensa exportar la aplicación, generar un
plug-in basado en la configuración de aplicación o realizar otra gestión de aplicaciones en
el futuro. Las funciones de gestión de aplicación wsadmin o de consola administrativa no
reconocen los cambios realizados en los archivos de aplicación utilizando el despliegue
directo. Esas funciones sólo reconocen los archivos de aplicación que los programas
administrativos como la consola o wsadmin presentan durante la instalación de aplicación,
la actualización u otras funciones de gestión. Las funciones de gestión de aplicación
no reconoce los archivos cambiados por el despliegue directo.
Importante: No utilice el despliegue directo para actualizar los componentes en un célula
gestionada por el gestor de despliegue de producción. El despliegue directo es adecuado para el desarrollo y
realización de pruebas, pero supone riesgos inaceptables en los entornos
de producción. La resincronización completa o parcial podría borrar los componentes desplegados directamente. Al ejecutar el mandato restoreconfig se pueden sobregrabar los cambios realizados en los archivos de aplicación ampliados. De forma adicional, los componentes desplegados dinámicamente no se migran entre versiones de WebSphere Application Server. Para añadir nuevos componentes o módulos a una
aplicación de empresa, vuelva a ensamblar el archivo EAR de la aplicación
para que tenga los nuevos componentes o módulos y, a continuación, vuelva
a desplegar el archivo EAR.
Acerca de esta tarea
El despliegue directo es el proceso de añadir nuevos componentes (como
archivos WAR, archivos Jar de EJB, enterprise Java beans, servlets y
archivos JSP) a un servidor en ejecución sin tener que detener el proceso de servidor de aplicaciones y reiniciarlo de nuevo.
La recarga dinámica es la posibilidad de cambiar un componente existente sin necesidad de
reiniciar el servidor para que tenga efecto el cambio. La recarga dinámica
conlleva:
- Cambios en la implementación de un componente de aplicación, como el cambio de la implementación de un servlet
- Cambios en los valores de la aplicación, como el cambio del descriptor de despliegue de un módulo web
Al contrario de lo que sucede con los cambios que se realizan en una aplicación desplegada, que se describen en Actualización de archivos de aplicación empresarial, los cambios efectuados con despliegue o recarga dinámica no utilizan la consola administrativa ni un mandato de creación de scripts wsadmin. Debe manipular directamente los
archivos de aplicaciones en el servidor donde se despliegue la aplicación.
Si la aplicación que está actualizando
está desplegada en un servidor que tiene la
política del cargador de clase de
aplicación establecida en Sencillo, quizá no pueda volver a cargar
dinámicamente la aplicación. Como mínimo, debe reiniciar el servidor después de actualizar la aplicación.
Procedimiento
- Localice los archivos de aplicación ampliados.
Los archivos de aplicación
están en el directorio que especificó al instalar la aplicación o, si no especificó
ningún directorio de destino personalizado, están en el directorio de destino por omisión, raíz_servidor_aplicaciones/installedApps/nombre_célula.
El archivo EAR, ${APP_INSTALL_ROOT}/nombre_célula/nombre_aplicación.ear,
señala el directorio de destino. El archivo variables.xml del nodo define ${APP_INSTALL_ROOT}.
Es importante localizar los archivos de aplicación ampliados porque,
como parte de la instalación de aplicaciones, un WebSphere Application Server
descomprime partes del archivo EAR en el sistema de archivos del
sistema que ejecutará la aplicación. Estos archivos ampliados son los que el servidor examina al ejecutar la
aplicación. Si no puede localizar los archivos de aplicación ampliados,
consulte el atributo binariesURL en el archivo deployment.xml correspondiente a
la aplicación. El atributo indica la ubicación que la ejecución utiliza para encontrar los archivos de aplicación.
Durante el resto de esta información sobre el despliegue directo y la recarga dinámica, el
dir_raíz_aplicación representa el directorio raíz de los archivos de aplicación ampliados.
- Localice los archivos de metadatos de aplicación. Los archivos de metadatos incluyen los descriptores
de despliegue (web.xml, application.xml, ejb-jar.xml y similares), los archivos de enlaces (ibm-web-bnd.xmi, ibm-app-bnd.xmi y similares) y los archivos de extensiones (ibm-web-ext.xmi, ibm-app-ext.xmi y similares).
Los archivos XML de metadatos de una aplicación pueden cargarse de una de entre dos ubicaciones. Los archivos de metadatos se pueden cargar desde la misma ubicación que los archivos binarios de la aplicación (como raíz_aplicación/META-INF)
o se pueden cargar desde el árbol de configuración de WebSphere, ${CONFIG_ROOT}/cells/nombre_célula/applications
/nombre_EAR_aplicación/deployments/nombre_aplicación/.
El valor del distintivo useMetadataFromBinary especificado durante la instalación de la aplicación controla qué ubicación se utiliza. Si se especifica, los archivos de metadatos se cargan en la misma ubicación que los archivos binarios de la aplicación. Si no se especifica, los archivos de metadatos se cargan de la carpeta de despliegue de la aplicación del árbol de configuración.
Importante: Puede tener useMetadataFromBinaries=true,
cambiar una copia extraída de la aplicación utilizando el despliegue directo y hacer que los
cambios entren en vigor en tiempo de ejecución siguiendo el procedimiento de este tema. Sin embargo, las funciones de gestión de aplicación wsadmin o de consola no
reconocen los cambios realizados en los archivos de aplicación utilizando el despliegue
directo. Esas funciones sólo reconocen los archivos de aplicación originales y no los archivos
cambiados por el despliegue directo. No
utilice el despliegue directo si piensa exportar la aplicación, generar un
plug-in basado en la configuración de aplicación o realizar otra gestión de aplicaciones en
el futuro. El despliegue directo le permite cambiar rápidamente los archivos de aplicación;
no soporta el ciclo de vida de gestión completo de una aplicación.
Durante el resto de esta información, dir_raíz_metadatos representa la ubicación de los archivos de metadatos para la aplicación o el módulo especificado.
- Necesario: Si ejecuta WebSphere Application Server en
un grupo de máquinas que utilizan WebSphere Application Server, Network Deployment
y modifica una
aplicación en un nodo determinado, inhabilite la sincronización automática.
- Pulse en el árbol de navegación de consola.
- En la página Servicio de sincronización de archivos, deseleccione el recuadro de selección de
Sincronización automática y pulse Aceptar.
Al ejecutar WebSphere Application Server en
un grupo de máquinas que utilizan WebSphere Application Server, Network Deployment
y modifica un archivo
del disco en el directorio de aplicación ampliado de un nodo concreto,
puede perder estos cambios la próxima vez que se lleve a cabo la
sincronización de nodos. En el entorno de WebSphere Application Server, Network Deployment, la configuración almacenada por el gestor de despliegue es la copia maestra y cualquier cambio que se detecte entre dicha copia maestra y la copia que está en una máquina concreta desencadenará la bajada de la copia maestra al nodo.
- Opcional: Examine los valores especificados para Recargar las clases cuando se actualizan los archivos de aplicación e Intervalo de sondeo para los archivos actualizados en la página de valores de correspondiente al cargador de clases de la aplicación. .
Si está habilitada la recarga de clases y el intervalo de sondeo es mayor que cero
(0), los archivos de la aplicación se recargan después de su actualización.
Para los archivos JSP (JavaServer Pages) de un modulo web, un contenedor web recarga archivos JSP, sólo si la extensión de IBM jspReloadingEnabled del archivo ibm-web-ext.xmi está establecida en true. Puede establecer jspReloadingEnabled en true al editar los descriptores de despliegue ampliados del módulo web en una herramienta de ensamblaje.
- Modifique o añada los siguientes componentes o módulos según sea necesario:
- Para que los cambios entren en vigor, es posible que sea necesario iniciar, detener o reiniciar una aplicación.
Inicio o detención de aplicaciones de empresa proporciona información acerca de cómo utilizar la consola de administración para iniciar, detener o reiniciar una aplicación.
Inicio de aplicaciones mediante scripts wsadmin y Detención de aplicaciones mediante scripts wsadmin proporcionan información acerca de cómo utilizar la herramienta de scripts wsadmin.
- Si ha inhabilitado la sincronización automática en el paso 3,
vuelva a habilitarla:
- Vuelva a la página Servicio de sincronización de archivos.
- Seleccione Sincronización automática.
- Pulse Aceptar .
Resultados
Los archivos de aplicación se actualizan en el servidor.
Puesto que manipuló directamente los archivos de aplicación en el servidor, es posible que más adelante no pueda utilizar la consola administrativa
no el mandato de script wsadmin para trabajar con los archivos. Por ejemplo, si intenta exportar manualmente una aplicación modificada utilizando el botón Exportar en una página de la consola Aplicaciones de empresa, no se exportan los cambios manuales de la aplicación en el directorio installedApps. Para exportar estos cambios, debe copiar y mover los archivos de la aplicación manualmente.