Herramientas de prueba y documentación (servidor) - Notas del release

© 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.

Notas del release

1.0 Limitaciones
   1.1 La opción "Minimizar archivos de aplicación copiados en el servidor" está soportada en WebSphere Application Server 6.0.2.5 y posteriores
   1.2 Eliminación del módulo EJB compartido en varios proyectos EAR
   1.3 Ejecución de clientes de aplicación de WebSphere de varias hebras
2.0 Problemas conocidos y soluciones
   2.1 La sustitución de método en caliente no se aplica después de reanudar en modalidad de depuración
   2.2 El botón Eliminar en el recuadro de diálogo Gestionar servidores WebSphere compartidos no funciona.
   2.3 Es posible que el asistente Servidor nuevo no recupere la información de puerto correcta
   2.4 Creación de perfiles para WebSphere Application Server en un sistema de 64 bits
   2.5 Retrasos elevados al establecer una conexión RMI después de perder la conectividad de la red
   2.6 El servidor no puede recopilar diversos cambios en la página Editor de descriptores de despliegue de aplicaciones
   2.7 Error java.lang.NoClassDefFoundError cuando se añade un archivo JAR de programa de utilidad a las bibliotecas Web
   2.8 Las conexiones SOAP no pueden coexistir entre WebSphere Application Server V6.0 y V6.1
   2.9 El asistente Servidor nuevo puede tardar más de lo normal en finalizar cuando el servidor remoto está detenido
   2.10 Error al publicar una aplicación EAR que contiene una extensión de archivo .war en su directorio EarContent
   2.11 No es posible recopilar los cambios en los directorios de despliegue y publicación del servidor de WebSphere Application Server V5.1 remoto
   2.12 La publicación de aplicaciones de gran tamaño es más lenta que en la versión anterior
   2.13 Conmutación del tipo de conexión del servidor de un servidor WebSphere Application Server v6.1 seguro
   2.14 Se encuentra un error TargetInvocationException cuando se utiliza el asistente Creador de orígenes de datos y tablas
   2.15 Es posible que el servidor no se detenga completamente cuando se detenga el servidor utilizando la vista Servidores
   2.16 Los cambios del jar de EJB no se recopilan utilizando el cliente de prueba universal (UTC)

1.0 Limitaciones

1.1 La opción "Minimizar archivos de aplicación copiados en el servidor" está soportada por WebSphere Application Server 6.0.2.5 y posterior

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. 

1.2 Eliminación del módulo EJB compartido en varios proyectos EAR

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)

1.3 Ejecución de clientes de aplicación de WebSphere de varias hebras

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:

  1. 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
  2. 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.

2.0 Problemas conocidos y soluciones

2.1 La sustitución de método en caliente no se aplica después de reanudar en modalidad de depuración

Supongamos que tiene un proyecto, por ejemplo, un proyecto de aplicación cliente, con las siguientes configuraciones:

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.

2.2 El botón Eliminar en el recuadro de diálogo Gestionar servidores WebSphere compartidos no funciona.

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:

  1. En la barra de herramientas, seleccione Ventana > Preferencias.  Se abrirá el recuadro de diálogo Preferencias.
  2. En la página izquierda, seleccione Servidor > WebSphere > WebSphere v51.
  3. 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:

  1. 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.
  2. Suprima la entrada que hace referencia al servidor compartido que desea eliminar.
  3. 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.
  4. 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.

2.3 Es posible que el asistente Servidor nuevo no recupere la información de puerto correcta

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:

Método alternativo:

  1. 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 puertoDescripción del puertoNúmero de puerto predeterminadoEl número de puerto asignado
    SOAP_CONNECTOR_ADDRESS SOAP 8880
    BOOTSTRAP_ADDRESS RMI 2809
    WC_adminhost Consola administrativa 9060
    WC_defaulthost Transporte HTTP 9080
  2. Para conectarse al servidor, especifique el número de puerto RMI o SOAP correcto al crear el servidor.
  3. 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
  4. 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.

2.4 Creación de perfiles para WebSphere Application Server en un sistema de 64 bits

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.

2.5 Retrasos elevados al establecer una conexión RMI después de perder la conectividad de la red

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:

2.6 El servidor no puede recopilar diversos cambios en la página Despliegue del editor de descriptores de despliegue de aplicación

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:

  1. Detenga el servidor.
    1. En la vista Servidores, pulse con el botón derecho del ratón sobre el servidor y seleccione Detener.
    2. En la vista Servidores, espere que el estado del servidor aparezca como Detenido y, a continuación, lleve a cabo el siguiente paso. 
  2. 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.
  3. Inicie el servidor.
    1. En la vista servidores, pulse con el botón derecho del ratón y seleccione Iniciar.
    2. 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.
  4. 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.  

2.7 Error java.lang.NoClassDefFoundError cuando se añade un archivo JAR de programa de utilidad a las bibliotecas Web

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:

  1. 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.
  2. Pulse con el botón derecho del ratón sobre el proyecto Web y seleccione Propiedades.  Se abrirá el recuadro de diálogo Propiedades.
  3. Seleccione Dependencias de módulos J2EE.  
  4. 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.

2.8 Las conexiones SOAP no pueden coexistir entre WebSphere Application Server V6.0 y V6.1

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.

2.9 El asistente Servidor nuevo puede tardar más de lo normal en finalizar cuando el servidor remoto se ha detenido

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.

2.10 Error al publicar una aplicación EAR que contiene una extensión de archivo .war en su directorio EarContent

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:

2.11 No es posible recopilar los cambios en los directorios de despliegue y publicación del servidor WebSphere Application Server V5.1 remoto

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.

2.12 La publicación de aplicaciones de gran tamaño es más lenta que en la versión anterior

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.

2.13 Conmutación del tipo de conexión del servidor de un servidor WebSphere Application Server v6.1 seguro

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).

2.14 Se encuentra un error TargetInvocationException cuando se utiliza el asistente Creador de orígenes de datos y tablas

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.

2.15 Es posible que el servidor no se detenga completamente cuando se detenga el servidor utilizando la vista Servidores

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:

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.

2.16 Los cambios del jar de EJB no se recopilan utilizando el cliente de prueba universal (UTC)

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.