© Copyright International Business Machines Corporation 2006. Reservados todos los derechos. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
La opción Minimizar archivos de aplicación copiados en el servidor está soportada por WebSphere® Application Server 6.0.2.5 y posterior. En el editor de servidores de WebSphere Application Server V6.0 existe un recuadro de selección para la opción; la opción se ignora si está seleccionada para un servidor anterior a la versión 6.0.2.5.
Si un módulo de Enterprise JavaBean (EJB) se comparte entre varios proyectos EAR ejecutándose en WebSphere Application Server y se elimina un proyecto EAR del servidor, deben reiniciarse otros proyectos EAR antes de acceder a los recursos, como beans de EJB, en el proyectos de EJB.
Si no realiza esta acción, es posible que vea mensajes de error similares a los siguientes. Estos errores se producen porque el nombre de JNDI (Java Naming and Directory Interface) en el proyecto EJB se eliminan del servidor cuando se elimina el EAR.
Este es un mensaje de error de ejemplo:
00000028 SystemOut O javax.naming.NameNotFoundException: Contexto: myCell/nodes/myNode/servers/server1, name: ejb/ejbs/Session20Home: No se ha encontrado el primer componente en el nombre de Session20Home. [La excepción raíz es org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
en com.ibm.ws.naming.jndicos.CNContextImpl.processNotFoundException(CNContextImpl.java:4730)
en com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1907)
en com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1862)
en com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1552)
en com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.java:1354)
en com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:172)
en javax.naming.InitialContext.lookup(InitialContext.java:363)
en com.ibm.ivj.ejb.runtime.AbstractAccessBean.lookupAndCacheHome(AbstractAccessBean.java:224)
en com.ibm.ivj.ejb.runtime.AbstractAccessBean.getGlobalHome(AbstractAccessBean.java:216)
en com.ibm.ivj.ejb.runtime.AbstractAccessBean.getHome(AbstractAccessBean.java:249)
en ejbs.Session20AccessBean.ejbHome(Session20AccessBean.java:50)
en ejbs.Session20AccessBean.instantiateEJB(Session20AccessBean.java:80)
en ejbs.Session20AccessBean.foo(Session20AccessBean.java:91)
Debido a comportamientos e interacciones entre los entornos de ejecución de Eclipse y WebSphere, ya determinados pasos adicionales necesarios a la hora de ejecutar clientes de aplicaciones WebSphere de varias hebras utilizando el recuadro de diálogo Configuraciones de inicio de clientes de aplicación. El recuadro de diálogo Configuraciones de inicio de cliente de aplicación está disponible en la perspectiva J2EE al seleccionar Ejecución > Ejecutar en la barra de herramientas del producto. Si el cliente utiliza varias hebras, o bien utiliza infraestructuras que pueden utilizar hebras adicionales como Swing, deberá completar los siguientes pasos adicionales:
- En el recuadro de diálogo Configuraciones de inicio de cliente de aplicaciones, seleccione la pestaña Argumentos. En el recuadro de texto Argumentos de VM, especifique el siguiente parámetro:
-Dosgi.noShutdown=true- Asegúrese de que la aplicación de cliente llama a System.exit()
Si no se especifican, es posible que vea problemas relacionados con la carga de clases o con máquinas virtuales de Java™ (JVM) que no salen una vez que la aplicación se ha ejecutado completamente.
Supongamos que tiene un proyecto, por ejemplo, un proyecto de aplicación cliente, con las siguientes configuraciones:
- la faceta del proyecto de Java está establecida en la versión 1.4
- el tiempo de ejecución del servidor de destino de este proyecto tiene la opción de sustitución de método en caliente habilitada en la configuración del servidor
Es posible que experimente que el botón Reanudar en la vista Depurar no funciona correctamente. Por ejemplo, cuando se ejecuta la aplicación en el servidor en modalidad de depuración, intenta cambiar el código durante la ejecución y, a continuación, utilizar el botón Reanudar para continuar depurando la aplicación. Es posible que experimente que la sustitución de método en caliente que cambia el código fuente no se aplican.
Pruebe a pulsar el botón Reanudar dos veces que todos los cambios surtan efecto.
Nota: Este problema no se produce cuando se selecciona la faceta de Java en la versión 5.0.
El recuadro de diálogo Eliminar en el recuadro de diálogo Gestionar servidores WebSphere compartidos no funciona correctamente.
Sugerencia: Para abrir el recuadro de diálogo Gestionar servidores WebSphere compartidos:
- En la barra de herramientas, seleccione Ventana > Preferencias. Se abrirá el recuadro de diálogo Preferencias.
- En la página izquierda, seleccione Servidor > WebSphere > WebSphere v51.
- En la página derecha, junto al campo Servidores WebSphere compartidos, pulse el botón Gestionar. Se abrirá el recuadro de diálogo Gestionar servidores WebSphere compartidos.
Si utiliza el botón Eliminar, el servidor aparecerá como eliminado. Sin embargo, si sale del recuadro de diálogo, vuelve a abrir el recuadro de diálogo y renueva la información del servidor remoto, el servidor eliminado previamente seguirá en el recuadro de diálogo.
Para solucionar el problema de forma alternativa, puede eliminar de forma manual la entrada del servidor compartido llevando a cabo los siguientes pasos:
- Abra el archivo id.txt que se encuentra en el siguiente directorio:
<directorio>/plugins/com.ibm.etools.websphere.tools*/properties
donde <directorio> es el directorio de instalación de Agent Controller.- Suprima la entrada que hace referencia al servidor compartido que desea eliminar.
- Elimine el directorio de despliegue de WebSphere especificado para dicho servidor compartido en particular durante la creación del servidor y todos sus subdirectorios. Ejemplos de subdirectorios a eliminar en el directorio de despliegue de WebSphere pueden ser: config, installedApps, temp y cualquier otro directorio o archivo en este directorio.
- En el recuadro de diálogo Gestionar servidores WebSphere compartidos, especifique un nombre de servidor y pulse el botón Renovar para verificar que ha eliminado satisfactoriamente el servidor compartido.
Si tiene servidores adicionales, como IBM HTTP Server, instalados en el mismo perfil de WebSphere Application Server v6.x, es posible que la página Valores del servidor WebSphere del asistente Servidor nuevo no encuentre la invocación a método remoto (RMI) o los números de puerto SOAP correctos. Además, es posible que no se recupere el número de puerto de la consola administrativa.
Cuando el asistente Servidor nuevo no puede encontrar los números de puerto reales definidos para un servidor, su comportamiento predeterminado es prerellenar los campos de puertos con los números de puerto predeterminados: 2809 para RMI y 8880 para SOAP.
En caso de que se definan números de puerto incorrectos, es posible que experimente los siguientes problemas:
- No es posible conectarse al nuevo servidor, ni iniciarlo o detenerlo.
- No es posible abrir la consola de administración desde este nuevo servidor, como resulta puede que reciba un error de puerto no definido de consola de administración.
- No es posible ejecutar aplicaciones en este servidor, el mandato Ejecutar en servidor no funciona
Método alternativo:
- Determine los valores de puerto de un perfil configurado haciendo referencia a sus archivos de configuración de servidor. Los valores de puerto se almacenan en el archivo serverindex.xml que se encuentra en el siguiente directorio:
<directorio>\profiles\<profileName>\config\cells\<cellName>\nodes\<nodeName>, donde <directorio> es el directorio de instalación de WebSphere Application Server.
Utilice el archivo serverindex.xml para rellenar la siguiente tabla para determinar los números de puerto reales definidos para el servidor:
Nombre de puerto Descripción del puerto Número de puerto predeterminado El número de puerto asignado SOAP_CONNECTOR_ADDRESS SOAP 8880 BOOTSTRAP_ADDRESS RMI 2809 WC_adminhost Consola administrativa 9060 WC_defaulthost Transporte HTTP 9080 - Para conectarse al servidor, especifique el número de puerto RMI o SOAP correcto al crear el servidor.
- Para iniciar la consola administrativa, utilice un navegador Web externo y escriba en el campo de dirección el URL al puerto correcto de la consola de administración:
http://<nombre_sistema>:<WC_adminhost>/IBM/console
Por ejemplo: http://localhost:9060/IBM/console- Para ejecutar aplicaciones en el servidor, emite un mandato Ejecutar en servidor. Cuando se abra el navegador Web, corrija el URL con el número de puerto de transporte HTTP del servidor.
http://<nombre_sistema>:<hostWC_predeterminado>/<ContextRoot>/<página_inicio_aplicación>
Por ejemplo: http://localhost:9080/MyApplication/index.jsp
Nota: Puede que los servidores definidos automáticamente en la vista Servidores no hagan referencia a los número de puertos correctos del servidor. Si este fuera el caso, utilice el mismo método alternativo anteriormente especificado.
La herramienta Gestión de perfiles es una herramienta de WebSphere Application Server que crea el perfil de cada entorno de tiempo de ejecución. Puede utilizar el espacio de trabajo para iniciar la herramienta Gestión de perfiles de WebSphere Application Server. Sin embargo, la herramienta Gestión de perfiles no funciona con un procesador de 64 bits, en su lugar utilice la herramientas de la línea de mandatos manageprofiles proporcionada por WebSphere Application Server.
En sistemas operativos Windows, si está utilizando el puerto de invocación a método remoto (RMI) para conectarse a WebSphere Application Server v6.x, es posible que sufra retrasos al establecer una conexión con el servidor después de perder la conectividad de la red. Esto puede producirse incluso si el servidor es local y la conectividad de la red se pierde sólo temporalmente, algo común en un entorno de red inalámbrica.
Si sabe que el servidor está funcionando, pero el estado en la vista Servidores muestra Detenido o Iniciándose, intente establecer una conexión con el servidor conmutando la conexión al servidor de RMI a SOAP. El estado del servidor debería cambiar a Iniciado.Hay un par de opciones disponibles para establecer una conexión con un servidor en un entorno de red inalámbrica:
- La opción más sencilla y segura es cambiar la conexión para que utilice el puerto SOAP. Después de perder la conectividad de la red, las conexiones SOAP tienen la capacidad de recuperarse más rápidamente en comparación con una conexión RMI.
- Si necesita utilizar una conexión RMI, puede intentar modificar los valores predeterminados del almacenamiento en memoria caché de DNS (Domain Name System) en el sistema operativo Windows. Para obtener más detalles, consulte el siguiente artículo de soporte de Microsoft:
http://support.microsoft.com/kb/318803
El sistema operativo Windows tiene una capacidad incoporada de almacenamiento en memoria caché de DNS que mantiene los nombres de host resueltos. Esto acelera el tiempo de respuesta de las búsquedas de DNS. La desventaja principal de este procedimiento es si falla una búsqueda de DNS. El sistema operativo almacena en la memoria caché el valor fallido durante un tiempo predeterminado de 300 segundos. Por lo tanto, incluso si el servidor DNS puede resolver la búsqueda inmediatamente después, no se volverá a intentar la búsqueda hasta que caduque el tiempo de la memoria caché. Como resultado, una búsqueda DNS fallida con los valores predeterminados puede tardar hasta 5 minutos antes de que se realice un intento real de búsqueda. Si se establece el tiempo de la memoria caché en 0 segundos se forzará al sistema operativo Windows a que nunca almacene en la memoria caché las consultas DNS fallidas y permitirá que se produzca la reconexión tan pronto como el DNS esté disponible.
El siguiente es un ejemplo de cómo se inhabilita el almacenamiento en memoria caché de DNS de las búsquedas fallidas en sistemas operativos Windows:
En la siguiente clave de registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Añada uno de los siguientes valores de registro:
- Para Windows XP/2003:
"MaxNegativeCacheTtl"=dword:00000000- Para Windows 2000:
"NegativeCacheTime"=dword:00000000
Volver a publicar la aplicación, reiniciar la aplicación o desinstalar y volver a instalar la aplicación no son acciones suficientes para aplicar una variedad de cambios de recursos definidos en la página Despliegue del editor de descriptores de despliegue de aplicación en el servidor. Un cambio en el nombre de la base de datos de un origen de datos en la página Despliegue del editor es un cambio conocido que el servidor no puede recopilar, es posible que haya otros cambios que el servidor no pueda recopilar.
Como método alternativo, siga estos pasos para aplicar los cambios en el servidor:
- Detenga el servidor.
- En la vista Servidores, pulse con el botón derecho del ratón sobre el servidor y seleccione Detener.
- En la vista Servidores, espere que el estado del servidor aparezca como Detenido y, a continuación, lleve a cabo el siguiente paso.
- Inicie el entorno de trabajo.
NOTA: Si el servidor no se inicia, necesitará utilizar las funciones del sistema operativo para detener el proceso java en el que se está ejecutando el servidor. Como alternativa, puede reiniciar el área de trabajo e intentar volver a iniciar el servidor.- Inicie el servidor.
- En la vista servidores, pulse con el botón derecho del ratón y seleccione Iniciar.
- En la vista Servidores, espere a que finalice la nueva publicación y a que el estado del servidor aparezca como Iniciado y, a continuación, lleve a cabo el siguiente paso.
- Ejecute la aplicación en el servidor, por ejemplo, utilice el mandato Ejecutar en servidor. Como resultado, el servidor debería ahora poder recopilar los cambios del editor de descriptores de despliegue de aplicación.
Si añade un archivo JAR de programa de utilidad a las bibliotecas Web y hace referencia a las clases dentro del archivo JAR en el código, es posible que obtenga un error java.lang.NoClassDefFoundError al intentar ejecutar la aplicación Java en el servidor.
El método alternativo consiste en, después de añadir un archivo JAR de programa de utilidad al módulo EAR, añádalo al archivo JAR a las dependencias de módulos J2EE del proyecto Web, llevando a cabo los siguientes pasos:
- Añada un archivo JAR al módulo EAR. Consulte el tema Añadir archivos JAR de programa de utilidad de producto en la ayuda del producto para obtener más detalles.
- Pulse con el botón derecho del ratón sobre el proyecto Web y seleccione Propiedades. Se abrirá el recuadro de diálogo Propiedades.
- Seleccione Dependencias de módulos J2EE.
- En la pestaña Módulos J2EE, en la columna JAR/Módulo, seleccione el recuadro de selección junto al archivo JAR del programa de utilidad.
Si WebSphere Application Server V6.1 se está ejecutando en una conexión SOAP segura, otra conexión SOAP segura con un servidor WebSphere Application Server V6.0 fallará. El mismo problema se producirá en orden inverso, es decir, WebSphere Application Server V6.0 ejecutándose en una conexión SOAP segura hará que falle una conexión SOAP segura con WebSphere Application Server V6.1. Sin embargo, el problema no se produce si el servidor está definido en la vista Servidores y su estado está vacío.
El método temporal es utilizar una invocación a método remoto (RMI) al servidor en lugar de una conexión SOAP, o utilizar una conexión SOAP no segura.
Si el servidor remoto se ha detenido, el asistente Servidor nuevo puede tardar mucho tiempo en finalizar después de pulsar el botón Finalizar. Un método alternativo es iniciar el servidor remoto antes de pulsar el botón Finalizar en el asistente Servidor nuevo.
Si un archivo con una extensión .war se coloca en la carpeta EarContent de un proyecto EAR y no está definido como un módulo Web en el archivo application.xml, la aplicación empresarial no puede publicar en el servidor resultando en el siguiente mensaje de error de ejemplo:
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0034E No se ha podido abrir el archivador anidado "abc.war" en "D:\myworkspace\PublishEAR\EarContent"La causa de este error es que el área de ejecución no puede manejar el archivo correctamente como un módulo Web. Elija uno de los siguientes métodos alternativos:
- Si el archivo es un módulo Web, añada el archivo como un módulo a la aplicación empresarial. Para obtener más detalles, consulte el tema Adición de módulos a una aplicación empresarial en la ayuda del producto.
- Si el archivo no es un módulo Web, una posibilidad para solucionar el problema sería cambiar la extensión del archivo a otra distinta de .war, por ejemplo a .jar
Con un servidor remoto de WebSphere Application Server V5.1 o un servidor remoto de WebSphere Application Server V5.1 Express, si cambia el directorio de despliegue y el directorio de publicación en el editor del servidor y, a continuación, vuelve a publicar la aplicación, la aplicación continúa publicando en el destino anterior. Como resultado, no se aplicarán los cambios en los directorios de publicación y de despliegue. Este problema se produce cuando se utilizan los métodos de copia local o de FTP.
El método alternativo es reiniciar el área de trabajo. Como resultado, los cambios de configuración del directorio de publicación y del directorio de despliegue deberían surtir efecto.
Para dar soporte a un método más flexible para el almacenamiento de proyectos, la técnica para publicar aplicaciones ha cambiado. Las aplicaciones se copian ahora antes de ser copiadas al servidor. Si la aplicación es de gran tamaño, por ejemplo, mayor de 100 megabytes, esta operación de copia utilizada para el mandato de publicación tardará más tiempo comparado con lo que tardaría en la versión anterior.
No hay método alternativo en la actualidad. IBM® está trabajando en una actualización que eliminará la necesidad de realizar esta nueva operación de copia en la mayoría de los casos.
Si se inicia un servidor WebSphere Application Server v6.1 seguro y en el editor del servidor se cambia el tipo de conexión del servidor a invocación a método remoto (RMI) o SOAP, es posible que vea el siguiente mensaje de error de publicación después de guardar los cambios en el editor del servidor:
La publicación no se ha ejecutado ya que no se ha iniciado el servidor. Inicie el servidor antes de realizar la operación de publicación.
Puede ignorar este error con toda seguridad. Como alternativa, después de que el estado del servidor en la vista Servidores sea Iniciado, puede completar un mandato de publicación (en la vista Servidores, pulse con el botón derecho del ratón y seleccione Publicar).
Cuando intenta generar un origen de datos utilizando el asistente Creador de orígenes de datos y tablas, es posible que encuentre un error TargetInvocationException en la sección Detalles del recuadro de diálogo Resultados del Creador de orígenes de datos y tablas.
La causa del error TargetInvocationException puede producirse si importa un intercambio de proyectos que contenga orígenes de datos con el mismo nombre JNDI (Java Naming and Directory Interface).
Para solucionar el error TargetInvocationException de forma alternativa, verifique si ya se ha definido un origen de datos con el mismo nombre JNDI en el área de trabajo. Si es así, elimínelo de la página Despliegue del Editor de descriptores de despliegue de aplicaciones y vuelva a crear el origen de datos utilizando un nombre JNDI diferente. El nombre JNDI necesita ser exclusivo ya que es un nombre y porque se utiliza el servicio de búsqueda para enlazar un bean empresarial a un origen de datos.
Al detener el servidor en la vista Servidores, es posible que el servidor no se detenga completamente. La vista Servidores aparece como Detenida pero es posible que el proceso no responda. Esto se produce generalmente cuando artefactos como la aplicación o el área de trabajo siguen haciendo referencia a las clases en el servidor. Las siguientes son situaciones de ejemplo:
- Aplicaciones que se encuentran en bucles sin fin, o bien aplicaciones que siguen haciendo referencia a algunas clases en el servidor.
- Aplicaciones que se conectan a bases de datos Cloudscape o Derby sin limpiar la conexión
- Se utiliza el botón Probar conexión en el asistente Nueva conexión en las herramientas de datos para una conexión a una base de datos Cloudscape o Derby sin desconectarse de la base de datos
Restricción: Debido a una restricción de configuración de Cloudscape o Derb, no está soportado establecer varias varias conexiones con una sola base de datos Cloudscape o Derby. Si realiza el mantenimiento de la conexión con la base de datos en el Explorador de bases de datos y un servidor intenta establecer otra conexión con Cloudscape o Derby a través de un origen de datos, la segunda conexión fallará. Como resultado, necesitará cerrar la conexión desde el Explorador de bases de datos antes de que un servidor pueda establecer una conexión con una base de datos Cloudscape o Derby.
Método alternativo: Utilice las funciones del sistema operativo para detener el proceso java en el que se está ejecutando el servidor. Como alternativa, puede reiniciar el área de trabajo para forzar que se libere la referencia. En la última situación de ejemplo descrita en el tercer punto es posible utilizar el Explorador de bases de datos para conectarse y desconectarse de la conexión de base de datos Cloudscape o Derby.
Es posible que al publicar recursos en el servidor, por ejemplo, un bean empresarial, y utilizando el cliente de prueba universal (UTC) para probar un EJB, el archivo JAR se bloquee y no pueda ser actualizado. Esto hace que los cambios que se han realizado en la herramienta no sean recopilados durante la prueba del EJB. Una vez que el UTC carga el archivo JAR del EJB, el archivo JAR permanece bloqueado hasta que se elimina y se vuelve a añadir la aplicación, o bien hasta que se reinicia el servidor.
Método alternativo: Utilice el UTC en entornos de desarrollo donde los recursos de la aplicación estén fuera del área de trabajo y no se ejecuten en el servidor. Esto puede configurarse utilizando el asistente Servidor nuevo, o cambiarlo posteriormente utilizando el editor del servidor seleccionando Ejecutar servidor con recursos dentro del área de trabajo en las opciones de publicación. Esto permite que se actualicen archivos individuales dentro del proyecto EJB sin que sea necesario sustituir completamente el archivo JAR de EJB.
Después de haber probado completamente la aplicación, puede publicarla en el servidor utilizando la opción de publicación Ejecutar servidor con los recursos en el servidor.