Sugerencias de resolución de problemas del cliente de aplicación

Depure los problemas comunes del cliente de aplicaciones Java™ Platform, Enterprise Edition (Java EE) utilizando esta guía de resolución de problemas. Revise las entradas de rastreo de una de las excepciones de cliente de aplicación Java EE y, a continuación, localice la excepción en la guía.

Algunos de los errores de la guía son ejemplos, y el error real que reciba puede ser diferente del que se muestra aquí. Puede resultarle muy útil volver a ejecutar el mandato launchClient especificando la opción -CCverbose=true. Esta opción proporciona información adicional cuando se inicializa la ejecución del cliente de aplicación Java EE.

Error: java.lang.NoClassDefFoundError

Explicación	Causas posibles	Respuesta recomendada
Esta excepción se genera cuando el código Java no puede cargar la clase especificada.	La clase no es válida o no existe Problema de classpath Problema de manifiesto	Compruebe si la clase especificada existe en un archivo JAR (Java Archive) dentro del archivo EAR (Enterprise Archive). Si es así, debe asegurarse de que la vía de acceso de la clase sea correcta. Por ejemplo, si recibe la excepción: java.lang.NoClassDefFoundError: WebSphereSamples.HelloEJB.HelloHome Compruebe que exista la clase HelloHome en uno de los archivos JAR del archivo EAR. Si existe, compruebe que la vía de acceso para la clase sea WebSphereSamples.HelloEJB.

Si tanto la clase como la vía de acceso son correctas, el problema reside en la classpath. Lo más probable es que no esté incluido el archivo JAR de clase con error en el manifiesto de archivo JAR de cliente. Para comprobarlo, realice los pasos siguientes:

Abra el archivo EAR con una herramienta de ensamblaje y pulse en el cliente de aplicación.
Añada los nombres de los demás archivos JAR del archivo EAR al campo Classpath.

Esta excepción suele deberse a que falta un nombre de módulo EJB (Enterprise Java Beans) en el campo Classpath.

Si dispone de varios archivos JAR para entrar en el campo Classpath, asegúrese de separar los nombres JAR con espacios.

Si el problema persiste, se debe a que se carga una clase desde el sistema de archivos en lugar del archivo EAR. Este error es difícil de depurar ya que la clase anómala no es la que está especificada en la excepción. Sino que se carga otra clase desde el sistema de archivos antes de la clase especificada en la excepción. Para corregir este error, revise las classpaths especificadas con la opción -CCclasspath y las varibles classpath configuradas con la Herramienta de configuración de recursos del cliente de aplicación.

Busque las clases que existan también en el archivo EAR. Debe resolver la situación en la que se encuentra una de las clases en el sistema de archivos en lugar de en el archivo EAR. Elimine las entradas de las vías de acceso de clase o incluya los archivos JAR y las clases en el archivo EAR en lugar de hacer referencia a ellos en el sistema de archivos.

Si utiliza el parámetro -CCclasspath o las variables classpath de recursos en la herramienta y ha configurado varios archivos JAR o clases, compruebe que estén separados por el carácter correcto para su sistema operativo. A diferencia del campo Classpath, estos campos de classpath utilizan caracteres separadores específicos de la plataforma.

[Linux] [AIX] [HP-UX] [Solaris] El carácter separador es un signo de dos puntos.

[Windows] El carácter separador es un signo de punto y coma.

Sugerencia: El tiempo de ejecución del cliente de aplicaciones no utiliza la vía de acceso de clases del sistema si utiliza los archivos de shell o por lotes launchClient . En este caso, la variable classpath del sistema no ocasionará este problema. No obstante, si carga directamente la clase launchClient, tiene que buscar también en la variable classpath del sistema.

Error: com.ibm.websphere.naming.CannotInstantiateObjectException

Error: com.ibm.websphere.naming.CannotInstantiateObjectException: Se ha producido una excepción al intentar obtener una instancia del objeto para el objeto de referencia especificado. [La excepción raíz es javax.naming.NameNotFoundException: xxxxxxxxxx]

Explicación	Causas posibles	Respuesta recomendada
Esta excepción se produce cuando realiza una búsqueda de objetos que no están instalados en el host del servidor. El programa puede buscar el nombre en el espacio de nombres JNDI (Java Naming and Directory Interface) del cliente local, pero ha recibido una excepción NameNotFoundException porque no está ubicado en el servidor de host. Un ejemplo típico es buscar un componente EJB que no esté instalado en el servidor de host al que accede. Esta excepción también puede ocurrir si el nombre JNDI que ha configurado en el módulo del cliente de aplicación no coincide con el nombre JNDI real del recurso en el servidor de host.	Se ha invocado un servidor de host incorrecto El recurso no está definido El recurso no está instalado No se ha iniciado el servidor de aplicaciones La configuración de JNDI no es válida	Si está accediendo al servidor de host erróneo, vuelva a ejecutar el mandato `launchClient`, pero el parámetro -CCBootstrapHost debe especificar el nombre del servidor de host correcto. Si está accediendo al servidor de host correcto, utilice la herramienta de línea de mandatos `dumpnamespace` del producto para ver una lista del espacio de nombres JNDI del servidor de host. Si no ve el nombre del objeto anómalo, es posible que el recurso no esté instalado en el servidor de host o que el servidor de aplicaciones correcto no se haya iniciado. Si determina que el recurso está ya instalado e iniciado, el nombre JNDI de la aplicación cliente no coincide con el nombre JNDI global en el servidor de host. Utilice una herramienta de ensamblaje para comparar los valores de los enlaces JNDI del nombre de objeto erróneo en la aplicación cliente con el valor de los enlaces JNDI del objeto en la aplicación servidor del host. Los valores deben coincidir.

Error: javax.naming.ServiceUnavailableException

Error: javax.naming.ServiceUnavailableException: Se ha producido un error de comunicación al intentar obtener un contexto inicial utilizando el url del proveedor: "iiop://[invalidhostname]". Asegúrese de que la información de host y puerto es correcta y que el servidor identificado por el URL del proveedor es un servidor de nombres en ejecución. Si no se especifica número de puerto, se utiliza el valor predeterminado, 2809. Otras posibles causas son debidas a la configuración de la red de la estación de trabajo o del entorno de red. La excepción raíz es org.omg.CORBA.INTERNAL: JORB0050E: En Profile.getIPAddress(), InetAddress.getByName[invalidhostname] ha lanzado una excepción UnknownHostException. Código menor: 4942F5B6 Finalizado: Quizás

Explicación	Causas posibles	Respuesta recomendada
Esta excepción se produce si especifica un nombre de servidor de host no válido.	Se ha invocado un servidor de host incorrecto El nombre de servidor de host no es válido	Vuelva a ejecutar el mandato `launchClient` y especifique el nombre correcto del servidor de host con el parámetro -CCBootstrapHost.

Error: javax.naming.CommunicationException

Error: javax.naming.CommunicationException: No se ha podido obtener un contexto inicial por un error de comunicación. Como no se ha especificado URL de proveedor, se ha utilizado un host y puerto de la rutina de carga de un ORB existente o bien se ha creado e inicializado una nueva instancia de ORB con el host de rutina de carga predeterminado "localhost" y el puerto de rutina de carga predeterminado 2809. Asegúrese de que el host y puerto de la rutina de carga de ORB se resuelven para un servidor de nombres en ejecución. La excepción raíz es org.omg.CORBA.COMM_FAILURE: WRITE_ERROR_SEND_1 Código menor: 49421050 Finalizado: No

Explicación	Causas posibles	Respuesta recomendada
Esta excepción se produce cuando se ejecuta el mandato `launchClient` en un servidor de host que no ha iniciado el servidor de aplicaciones. También recibirá esta excepción si especifica un nombre de servidor de host no válido. Esto puede suceder si no especifica un nombre de servidor de host cuando ejecuta la herramienta launchClient. El comportamiento predeterminado es que la herramienta launchClient se ejecute en el host local, porque WebSphere® Application Server no conoce el nombre del servidor host. Este comportamiento predeterminado sólo funciona cuando se ejecuta el cliente en la misma máquina con WebSphere Application Server instalado.	Se ha invocado un servidor de host incorrecto El nombre de servidor de host no es válido Hay una referencia a localhost que no es válida No se ha iniciado el servidor de aplicaciones El puerto de la rutina de carga no es válido	Si no está ejecutando el servidor de host correcto, ejecute de nuevo el mandato `launchClient` y especifique el nombre de servidor del host con el parámetro `-CCBootstrapHost`. De lo contrario, inicie el servidor de aplicaciones en el servidor de host y vuelva a ejecutar el mandato `launchClient`.

Error de Windows: javax.naming.CommunicationException

Error: javax.naming.CommunicationException: No se ha podido obtener el wasuser6 del patrón debido a la excepción siguiente javax.naming.CommunicationException: ha fallado el enlace simple: ubicación_servidor. La excepción raíz es javax.net.ssl.SSLHandshakeException: El host remoto ha cerrado la conexión durante la conexión inicial.

Explicación	Causas posibles	Respuesta recomendada
Esta excepción se produce cuando habilita la seguridad administrativa, de aplicaciones y Java 2 utilizando el registro de usuarios LDAP.	La opción SSL habilitado está seleccionada en el panel de configuración del registro LDAP autónomo. El número de puerto LDAP o el nombre de host es erróneo. El certificado del servidor LDAP es erróneo o caducado en el servidor LDAP. La entidad emisora de certificados (CA) no se importa a WebSphere Application Server, o es incorrecta. La configuración SSL (Secure Sockets Layer) es errónea. Existe un problema de red.	Deseleccione la opción SSL habilitado e intente volver a realizar la conexión. La opción SSL habilitado especifica si se deben proteger las conexiones entre el plug-in de WebSphere Application Server y el servidor de aplicaciones con SSL. El valor predeterminado es no utilizar SSL.

Error: javax.naming.NameNotFoundException

Error: javax.naming.NameNotFoundException: no se ha encontrado comp/env/ejb en el contexto "java:"

Explicación	Causas posibles	Respuesta recomendada
Esta excepción se emite cuando el código Java no puede localizar el nombre especificado en el espacio de nombres JNDI local.	No se dispone de información de enlace para el nombre especificado La información de enlace del nombre especificado es incorrecta Se ha utilizado un cargador de clases incorrecto para cargar una de las clases del programa Una referencia de recurso no incluye ninguna información de configuración de cliente	Abra el archivo EAR con una herramienta de ensamblaje y compruebe los enlaces del nombre con error. Compruebe que esta información es correcta. Se están utilizando Referencias de recursos, abra el archivo EAR con la Herramienta de configuración de recursos del cliente de aplicación, y compruebe que la Referencia de recurso tenga información de configuración del cliente y que el nombre de la Referencia de recurso coincida exactamente con el nombre JNDI de la configuración del cliente. Si los valores son correctos, podría tener un error de cargador de clases.

Error: java.lang.ClassCastException

Error: java.lang.ClassCastException: no se ha podido cargar la clase: org.omg.stub.WebSphereSamples.HelloEJB._HelloHome_Stub en com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(portableRemoteObject.java:269)

Explicación	Causas posibles	Respuesta recomendada
Esta excepción se produce cuando el programa de aplicación intenta buscar la clase local de EJB y los cargadores de clases no pueden encontrar los enlaces de cliente de EJB.	Los archivos *_Stub.class y _Tie.class no están en el archivo .jar de EJB. El cargador de clases no ha podido encontrar las clases	Consulte el archivo JAR EJB ubicado en el archivo EAR y verifique que la clase contiene los enlaces del lado del cliente EJB (Enterprise Java Beans). Estos son archivos de clase con nombres de archivo terminados en `_Stub` y `_Tie`. Si las clases de enlace están en el archivo JAR de EJB, es posible que tenga un error de cargador de clases.

Error: WSCL0210EError: java.lang.NoClassDefFoundError

Error: WSCL0210E: El archivo archivador de empresa [EAR file name] no se ha podido encontrar. com.ibm.websphere.client.applicationclient.ClientContainerException: com.ibm.etools.archive.exception.OpenFailureException

Explicación	Causas posibles	Respuesta recomendada
Este error se produce cuando el programa de tiempo de ejecución cliente de aplicación no puede leer el archivo EAR (Enterprise Archive).	La causa más probable de este error es que el sistema no ha podido encontrar el archivo EAR en la vía de acceso especificada en el mandato `launchClient`.	Verifique que la vía de acceso y el nombre de archivo especificados en el mandato `launchclient` son correctos. Si está ejecutando en el sistema operativo Windows y la vía de acceso y el nombre de archivo son correctos, utilice una versión corta de la vía de acceso y el nombre de archivo (nombre de archivo de 8 caracteres y extensión de 3 caracteres).

El mandato launchClient parece que se cuelga y no vuelve a la línea de mandatos cuando finaliza la aplicación cliente.

Explicación	Causas posibles	Respuesta recomendada
Al ejecutar el cliente de aplicaciones utilizando el mandato `launchClient` , es posible que el tiempo de ejecución de WebSphere Application Server tenga que mostrar el diálogo de inicio de sesión de seguridad. Para visualizar este diálogo, el tiempo de ejecución de WebSphere Application Server crea una hebra AWT (Abstract Window Toolkit). Cuando la aplicación vuelve de su método principal al tiempo de ejecución del cliente de aplicaciones, el tiempo de ejecución del cliente de aplicaciones intenta volver al sistema operativo y finalizar el código de la máquina virtual Java (JVM). No obstante, como hay una hebra AWT, el código de JVM no finalizará hasta que se invoque `System.exit`.	El código de JVM no finaliza, porque hay una hebra AWT. El código Java requiere que se llame a `System.exit()` para finalizar las hebras AWT.	Modificar la aplicación para que invoque a `System.exit(0)` en su última sentencia. Utilizar el parámetro `-CCexitVM=true` cuando se invoca el mandato `launchClient`.

El soporte de IBM® dispone de documentos y herramientas que pueden ahorrarle tiempo a la hora de recopilar la información necesaria para resolver problemas. Antes de abrir un informe de problema, consulte la página del servicio de soporte: