© 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 versiones posteriores. En el editor de servidor de WebSphere Application Server V6.0, hay un recuadro para la opción; la opción se omite si se selecciona para el servidor antes de la versión 6.0.2.5.
Si un módulo Enterprise JavaBean (EJB) se comparte entre varios proyectos EAR que estén ejecutándose en a WebSphere Application Server y se elimina uno de los proyectos EAR del servidor, deben reiniciarse los demás proyectos EAR para que puedan acceder a los recursos, como por ejemplo los beans EJB, del proyecto EJB.
Si no lleva a cabo la acción, podrá ver mensajes de error parecidos a los que se muestran a continuación. Estos errores ocurren porque el nombre JNDI (Java Naming and Directory Interface) del proyecto EJB se elimina 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, nombre: ejb/ejbs/Session20Home: No se ha encontrado el primer componente del nombre 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 varios comportamientos en interacciones entre los entornos de tiempo de ejecución de Eclipse y WebSphere, hay varios pasos adicionales necesarios al ejecutar varios clientes de aplicaciones WebSphere mediante el recuadro de diálogo Configuraciones de lanzamiento de cliente de aplicaciones. El recuadro de diálogo Configuraciones de lanzamiento de cliente de aplicaciones está disponible a partir de la perspectiva J2EE cuando selecciona Ejecutar > Ejecutar... en la barra de herramientas del producto. Si el cliente utiliza varias hebras o utiliza infraestructuras que pueden utilizar hebras adicionales como por ejemplo Swing, debe seguir estos pasos adicionales
- En el recuadro de diálogo Configuraciones de lanzamiento de cliente de aplicaciones, seleccione la pestaña Argumentos. Bajo el recuadro de texto Argumentos de VM especifique el parámetro siguiente:
-Dosgi.noShutdown=true- Asegúrese de que la aplicación cliente llama a System.exit()
Si estos no se lleva a cabo, se producirán problemas relacionados con la carga de clases o con las máquinas virtuales de Java™ (JVM) que no salen una vez la aplicación se ha ejecutado completamente.
Suponga que tiene un proyecto, por ejemplo un proyecto de Cliente de aplicaciones con las configuraciones siguientes:
- la faceta de proyecto para Java está establecida en la versión 1.4
- el tiempo de ejecución del servidor destino para este proyecto tiene la opción de sustitución de método en caliente habilitada en la configuración del servidor
Puede ocurrir que el botón Reanudar de la vista Depurar no funcione adecuadamente. Por ejemplo, cuando ejecute la aplicación en el servidor en modalidad de depuración, puede intentar cambiar el origen en tiempo de ejecución y después utilizar el botón Reanudar para continuar depurando la aplicación. Puede ocurrir que los cambios de sustitución de método en caliente del código fuente no se apliquen.
Intente pulsar dos veces el botón Reanudar para permitir que los cambios de tiempo de ejecución surtan efecto.
Nota: este problema no se produce cuando establece la faceta de proyecto para Java en la versión 5.0.
El botón Eliminar del 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 abre el recuadro de diálogo Preferencias.
- En el panel de la izquierda, seleccione Servidor > WebSphere > WebSphere v51.
- En el panel de la derecha, junto al campo Servidores WebSphere compartidos, pulse el botón Gestionar. Se abre el recuadro de diálogo Gestionar servidores WebSphere compartidos.
Si utiliza el botón Eliminar, el servidor parece haberse eliminado. Sin embargo, si sale del recuadro de diálogo, vuelva a abrir el recuadro de diálogo y renueve la información del servidor remoto, el servidor eliminado anteriormente permanece en el recuadro de diálogo.
Para solucionar el problema, puede eliminar manualmente la entrada del servidor siguiendo estos pasos:
- Abra el archivo id.txt que está ubicado en el directorio siguiente:
<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 ese servidor compartidos determinado durante la creación del servidor y de todos sus subdirectorios. Los ejemplos de subdirectorios a eliminar bajo el directorio de despliegue de WebSphere son: config, installedApps, temp y otros directorios y archivos que residen bajo ese directorio.
- En el recuadro de diálogo Gestionar servidores WebSphere compartidos, especifique un nombre de host y pulse el botón Renovar para verificar que ha eliminado satisfactoriamente el servidor compartido.
Si tiene servidores adicionales, como por ejemplo IBM HTTP Server, instalados en el mismo perfil de WebSphere Application Server v6.x, la página Valores de servidor WebSphere del asistente Servidor nuevo no localiza los números de puerto de RMI (invocación e método remoto) ni de SOAP correctos. Además, es posible que no se recupere el número de puerto para la consola administrativa.
Cuando el asistente Servidor nuevo no puede encontrar los números de puerto reales definidos para un servidor, el comportamiento predeterminado consiste en cumplimentar previamente los campos de puerto con los números de puerto predeterminados: 2809 para RMI y 8880 para SOAP.
En el caso en que estén definidos los números de puerto correctos, pueden producirse los problemas siguientes:
- No se puede conectar con el servidor nuevo, como por ejemplo que no se puede iniciar ni detener el servidor.
- No se puede abrir la consola administrativa de este servidor nuevo y como resultado puede recibir un error de puerto de consola administrativa no definido.
- No se pueden ejecutar aplicaciones en este servidor, como por ejemplo que el mandato Ejecutar en servidores no funciona
Solución:
- Determine los valores de puerto de un perfil configurado haciendo referencia a los archivos de configuración del servidor correspondiente. Los valores del puerto se almacenan en el archivo serverindex.xml ubicado en el directorio siguiente:
<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 cumplimentar la tabla siguiente para determinar los números de puerto reales definidos para el servidor:
Nombre de puerto Descripción de puerto Número de puerto predeterminado Su 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 cuando lo cree.
- Para iniciar la consola administrativa, utilice un navegador Web externo y teclee en el campo de dirección el URL al puerto de la consola administrativa correcta:
http://<nombre_sistema>:<WC_adminhost>/IBM/console
Por ejemplo: http://localhost:9060/IBM/console- para ejecutar aplicaciones en el servidor, emita un mandato Ejecutar en servidor. Cuando se abre el navegador Web, corrija el URL con el número de puerto de transporte HTTP definido para el servidor.
http://<nombre_sistema>:<host_predeterminado_WC>/<ContextRoot>/<página_inicio_aplicación>
Por ejemplo: http://localhost:9080/MyApplication/index.jsp
Nota: los servidores definidos automáticamente en la vista Servidores no refieren los números de puerto correctos al servidor actual. Si este es el caso, utilice la misma solución.
La herramienta Gestión de perfiles es una herramienta de WebSphere Application Server que crea el perfil para cada entorno de tiempo de trabajo. Puede utilizar el entorno de trabajo para iniciar la herramienta Gestión de perfil 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 herramienta de línea de mandatos manageprofiles proporcionada por WebSphere Application Server.
En un sistema operativo Windows, si está utilizando el puerto de invocación a método remoto (RMI) para conectarse a WebSphere Application Server v6.x, se producirán retardos prolongados al establecer una conexión con el servidor después de perder la conectividad de red. Esto puede producirse incluso si el servidor es local y la conectividad de red se pierde solo temporalmente, lo que es habitual en un entorno de red inalámbrica.
Si sabe que se ha iniciado el servidor pero el estado que se muestra en la vista Servidores es Detenido o Iniciándose, intente ver si puede establecer una conexión con el servidor conmutando la conexión con el servidor de RMI a SOAP. El estado del servidor debe cambiar a Iniciado.Hay un par de opciones disponibles para establecer la conexión con un servidor en un entorno de red inalámbrica:
- La forma más fácil y segura consiste en conmutar la conexión para utilizar el puerto SOAP. Después de perder la conectividad de red, las conexiones SOAP tienen la posibilidad de recuperarse más rápidamente en comparación con una conexión RMI.
- Si debe utilizar una conexión RMI, puede intentar modificar los valores predeterminados que pertenecen a la memoria caché de Sistema de nombres de dominio (DNS) en el sistema operativo Windows. Para obtener detalles, consulte el siguiente artículo de soporte de Microsoft:
http://support.microsoft.com/kb/318803
El sistema operativo Windows tiene una memoria caché DNS incorporada que mantiene resueltos los nombres de host. Esto permite una vuelta más rápida al emitir búsquedas DNS. Sin embargo, esto presenta una desventaja si falla una búsqueda DNS. El sistema operativo Windows mantiene el valor fallido en memoria caché por un tiempo predeterminado de 300 segundos. Así, incluso si el servidor DNS puede resolver la búsqueda poco después, no intenta realmente la búsqueda hasta que caduca el tiempo en memoria caché. Como resultado, tras una búsqueda DNS fallida con valores predeterminados pueden pasar hasta 5 minutos hasta que se realiza un verdadero reintento de búsqueda. Al establecer el tiempo en memoria caché en 0 segundos se fuerza al sistema operativo Windows a no mantener en memoria caché consultas de búsqueda DNS fallidas y se permite que la reconexión se produzca en cuanto el DNS esté disponible.
A continuación se proporciona un ejemplo de inhabilitar la memoria caché DNS para búsquedas fallidas en sistemas operativos Windows:
En la clave del registro siguiente: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Añada uno de los valores del registro siguientes:
- Para Windows XP/2003:
"MaxNegativeCacheTtl"=dword:00000000- Para Windows 2000:
"NegativeCacheTime"=dword:00000000
Volver a publicar, reiniciar o desinstalar y reinstalar la aplicación no son acciones suficientes para aplicar en el servidor varios cambios de recursos definidos en la página Despliegue del Editor de descriptores de despliegue de aplicación. Un cambio en el nombre de base de datos de un origen de datos en la página Despliegue del editor es un cambio conocido que el servidor no puede recoger, puede haber otros cambios que el servidor no puede recoger.
Como solución, siga estos pasos para aplicar los cambios al servidor:
- Detenga el servidor.
- En la vista Servidores, pulse el botón derecho sobre el servidor y seleccione Detener.
- En la vista Servidores, espere a que el estado del servidor muestre Detenido y continúe con el paso siguiente.
- Inicie el entorno de trabajo.
NOTA: si el servidor no puede iniciarse, debe utilizar las funciones del sistema operativo para detener el proceso java en el que está ejecutándose el servidor. También puede reiniciar el entorno de trabajo y volver a iniciar el servidor.- Inicie el servidor.
- En la vista Servidores, pulse el botón derecho sobre el servidor y seleccione Iniciar.
- En la vista Servidores, espere a que finalice la republicación y a que se muestren el estado del servidor y la aplicación para visualizar Iniciado y después vaya al paso siguiente.
- Ejecute la aplicación en el servidor, por ejemplo utilice el mandato Ejecutar en servidor. Como resultado, el servidor debe ser ahora capaz de recoger los cambios del Editor de descriptores de despliegue de aplicación.
Si añade un archivo JAR de programas de utilidad a las Bibliotecas Web para un proyecto Web y en el código hace referencia a clases que estén dentro del archivo JAR, podrá obtener un error java.lang.NoClassDefFoundError cuando intente ejecutar la aplicación en el servidor.
La solución se aplica después de añadir un archivo JAR de programa de utilidad al módulo JAR, a continuación añada el archivo JAR a las dependencias de Módulos J2EE del proyecto Web completando los pasos siguientes:
- Añada un archivo JAR de programas de utilidad al módulo EAR. Consulte el tema Añadir archivos JAR de programas de utilidad de la documentación del producto para conocer los detalles.
- Pulse con el botón derecho sobre el proyecto Web y seleccione Propiedades. Se abre el recuadro de diálogo Propiedades.
- Seleccione Dependencias de módulos J2EE.
- En la pestaña Módulos J2EE bajo la columna JAR/Módulo, marque el recuadro de selección junto al archivo JAR de programas de utilidad.
Si WebSphere Application Server V6.1 está ejecutándose en una conexión SOAP segura, otra conexión SOAP segura con WebSphere Application Server V6.0 fallará. El mismo problema se produce a la inversa, si WebSphere Application Server V6.0 está ejecutándose en una conexión SOAP segura, fallará 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á en blanco.
La solución consiste en utilizar una conexión de invocación a método remoto (RMI) segura con el servidor en lugar de la conexión SOAP, o utilizar una conexión SOAP no segura.
Si el servidor remoto está detenido, el asistente Servidor nuevo puede tardar más en completarse después de pulsar el botón Finalizar. Una solución consiste en 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 módulo Web en el archivo application.xml, la aplicación empresarial no puede publicarse en el servidor con el mensaje de error de ejemplo siguiente:
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 entorno de trabajo no puede manejar correctamente el archivo como módulo Web. Elija una de las soluciones siguientes:
- Si el archivo es un módulo Web, añada el archivo como módulo a la aplicación de empresa. Para conocer detalles, consulte el tema Añadir módulos a una aplicación de empresa en la ayuda del producto.
- Si el archivo no es un módulo Web, una sugerencia para solucionar el problema de publicación consiste en cambiar la extensión de archivo por otra extensión que no sea .war, por ejemplo por .jar
Para un WebSphere Application Server V5.1 remoto o una edición WebSphere Application Server V5.1 Express remota, si cambia el directorio de despliegue y publicación en el editor del servidor y después vuelve a publicar la aplicación, la aplicación continúa publicándose en el destino anterior. Como resultado, los cambios en los directorios de publicación y despliegue no se aplican. Este problema ocurre cuando se utilizan métodos de copia local o FTP.
La solución consiste en reiniciar el entorno de trabajo. Como resultado, los cambios de configuración en cuanto al directorio de publicación y al directorio de publicación deben surtir efecto.
Para dar soporte a un procedimiento más flexible para almacenar proyectos, la técnica para publicar aplicaciones ha cambiado. Ahora las aplicaciones se copian antes de publicarse en el servidor. Si la aplicación es grande, por ejemplo más de 100 megabytes, esta operación de copia utilizad para el mandato de publicación tardará más tiempo de lo acostumbrado en la versión anterior.
Actualmente, no hay solución. IBM está trabajando en una actualización que eliminará la necesidad de realizar esta operación de copia nueva para la mayoría de los casos.
Si se inicia un WebSphere Application Server v6.1 seguro y en el editor del servidor cambia el tipo de conexión del servidor por la invocación a método remoto (RMI) o por SOAP, verá el mensaje de error de fallo en la publicación después de guardar los cambios en el editor del servidor:
La publicación no se realiza porque no se ha iniciado el servidor. Inicie el servidor antes de realizar la operación de publicación.
Puede pasar por alto tranquilamente el error. Después de que el estado del servidor de la vista Servidores sea Iniciado, también puede completar un mandato de publicación (en la vista Servidores, pulse con el botón derecho sobre el servidor y seleccione Publicar.)
Cuando intente generar un origen de datos mediante el asistente Creador de orígenes de datos y tablas encontrará un error TargetInvocationException en la sección Detalles del recuadro de diálogo Resultados de creación de orígenes de datos y tablas.
La causa del error TargetInvocationException puede producirse si importa un intercambio de proyectos que contiene orígenes de datos definidos con el mismo nombre JNDI (Java Naming and Directory Interface.)
Para solucionar el error TargetInvocationException, verifique si un origen de datos con el mismo nombre JNDI ya está definido en el entorno de trabajo. Si es así, elimínelo de la página Despliegue del editor de Descriptores de despliegue de la aplicación y vuelva a crear el origen de datos utilizando un nombre JNDI diferente. El nombre JNDI debe ser exclusivo ya que se trata de un servicio de denominación y búsqueda que se utiliza para enlazar un bean de empresa a un origen de datos.
Al detener el servidor desde la vista Servidores, el servidor no se detendrá completamente. En la vista Servidores aparece como Detenido pero el proceso servidor estará en un estado sin respuesta. Normalmente esto se produce cuando los artefactos como por ejemplo la aplicación o el entorno de trabajo permanezcan colgados de referencias a clases del servidor. Estos son casos de ejemplo:
- Aplicaciones que están en bucles infinitos o aplicaciones colgadas de referencias a algunas clases del servidor
- Aplicaciones que establecen una conexión de base de datos Cloudscape o Derby sin limpiar su conexión
- Utilizar el botón Probar conexión en el asistente Conexión nueva de las herramientas de datos para abrir una conexión con una base de datos Cloudscape o Derby sin desconectar de la base de datos
Restricción: no están soportadas varias conexiones a una sola base de datos Cloudscape o Derby debido a una restricción de la configuración de Cloudscape o Derby. Si mantiene la conexión de base de datos a la base de datos del Explorador de base de datos y un servidor intenta establecer otra conexión Cloudscape o Derby a través de un origen de datos, la segunda conexión fallará. Como resultado, debe cerrar la conexión del Explorador de base de datos para que un servidor pueda establecer una conexión con la base de datos Cloudscape o Derby.
Para solucionar el problema, debe utilizar las funciones del sistema operativo para detener el proceso java sobre el que el servidor está ejecutándose. También puede reiniciar el entorno de trabajo para forzar la liberación de la referencia. Como en el último caso de ejemplo descrito en el tercer punto, puede utilizar la vista Explorador de base de datos para conectarse a y después desconectarse de la base de datos Cloudscape o Derby.
Es posible que cuando publique recursos en el servidor, por ejemplo un bean de empresa y utilice el cliente de prueba universal (UTC) para probar un EJB, el archivo JAR se bloquee y no pueda actualizarse. Esto implica que los cambios realizados en la herramienta no se recogerán durante la prueba del EJB. Una vez el UTC carga el archivo JAR de EJB, el archivo JAR permanece bloqueado hasta que la aplicación se elimina y vuelve a añadirse o hasta que se reinicia el servidor.
La solución consiste en utilizar el UTC en el entorno de desarrollo en el que los recursos de la aplicación se ejecutan fuera del espacio de trabajo y no se ejecutan en el servidor. Esto puede configurarse mediante el asistente Servidor nuevo o cambiarse posteriormente mediante el editor del servidor seleccionando Ejecutar servidor con recursos en el espacio de trabajo bajo las Opciones de publicación. Esto permite que los archivos individuales del proyecto EJB se actualicen sin que sea necesaria una sustitución completa de todo el archivo JAR de EJB.
Una vez que la aplicación se ha probado completamente, puede publicarse en el servidor mediante la opción de publicación Ejecutar servidor con recursos en Servidor.