Tipps zur Fehlerbehebung bei Anwendungsclients

Allgemeines debuggen Java™ Platform, Enterprise Edition ( Java EE ) Anwendungsclientprobleme mithilfe dieses Handbuchs zur Fehlerbehebung. Sehen Sie sich die Traceeinträge für eine der Ausnahmen des Java EE-Anwendungsclients an und suchen Sie dann die Ausnahme in diesem Leitfaden zur Fehlerbehebung.

Einige der Fehler in der Anleitung sind Beispiele. Die tatsächlich empfangene Fehlermeldung kann geringfügig abweichen. Außerdem kann es von Nutzen sein, den Befehl launchClient mit der Option -CCverbose=true erneut auszuführen. Diese Option bietet zusätzliche Informationen, wenn die Laufzeitumgebung des Java EE-Anwendungsclients initialisiert wird.

Fehler: java.lang.NoClassDefFoundError

Erläuterung	Mögliche Ursachen	Empfohlene Maßnahmen
Diese Ausnahme wird ausgelöst, wenn Java-Code die angegebene Klasse nicht laden kann.	Ungültige oder nicht vorhandene Klasse Fehler im Klassenpfad Fehler im Manifest	Überprüfen Sie, ob die angegebene Klasse in einer Java Archive (JAR)-Datei innerhalb Ihrer Enterprise Archive (EAR)-Datei vorhanden ist. Falls ja, stellen Sie sicher, dass der Pfad für die Klasse korrekt ist. Sie erhalten beispielsweise die folgende Ausnahme: java.lang.NoClassDefFoundError: WebSphereSamples.HelloEJB.HelloHome Vergewissern Sie sich, dass die Klasse HelloHome in einer der JAR-Dateien in Ihrer EAR-Datei enthalten ist. Ist die Klasse vorhanden, stellen Sie sicher, dass der Pfad der Klasse WebSphereSamples.HelloEJB lautet.

Wenn die Klasse vorhanden und der Pfad korrekt ist, liegt ein Problem mit dem Klassenpfad vor. Höchstwahrscheinlich haben Sie die JAR-Datei der fehlerhaften Klasse im Manifest der JAR-Datei des Clients nicht richtig angegeben. Führen Sie zur Prüfung der Situation die folgenden Schritte durch:

Öffnen Sie Ihre EAR-Datei mit einem Assembliertool und wählen Sie den Anwendungsclient aus.
Fügen Sie die Namen der anderen JAR-Datei in der EAR-Datei dem Feld "Klassenpfad" hinzu.

Diese Ausnahme wird im Allgemeinen durch einen fehlenden Enterprise Java Beans (EJB)-Modulnamen im Feld „Classpath“ verursacht.

Wenn Sie mehrere JAR-Dateien im Feld "Klassenpfad" eingeben müssen, achten Sie darauf, die Namen der JAR-Dateien mit Leerzeichen voneinander zu trennen.

Tritt der Fehler weiterhin auf, wird eine Klasse aus dem Dateisystem und nicht aus der EAR-Datei geladen. Die Fehlerbehebung gestaltet sich in diesem Fall sehr schwierig, da die fehlerhafte Klasse nicht in der Ausnahme angegeben ist. Stattdessen wird eine andere Klasse aus dem Dateisystem geladen, bevor die in der Ausnahme genannte Klasse geladen werden kann. Prüfen Sie zur Behebung des Fehlers die angegebenen Klassenpfade mit der Option -CCclasspath und die konfigurierten Klassenpfade mit Application Client Resource Configuration Tool.

Suchen Sie nach Klassen, die auch in der EAR-Datei vorhanden sind. Sie müssen die Situation auflösen, in der eine der Klassen im Dateisystem statt in der EAR-Datei gefunden wird. Entfernen Sie Einträge aus den Klassenpfaden oder nehmen Sie die JAR-Dateien und Klassen in die EAR-Datei auf, anstatt sie über das Dateisystem zu referenzieren.

Wenn Sie den Parameter -CCclasspath oder Ressourcenklassenpfade im Tool verwenden und mehrere JAR-Dateien oder Klassen konfiguriert haben, müssen Sie sicherstellen, dass Sie bei der Angabe das richtige Trennzeichen für Ihr Betriebssystem verwenden. Anders als im Feld "Klassenpfad" werden in diesen Klassenpfadfeldern plattformspezifische Trennzeichen verwendet.

[Linux] [AIX] [HP-UX] [Solaris] Das Trennzeichen ist ein Doppelpunkt.

[Windows] Das Trennzeichen ist ein Semikolon.

Tipp: Der Systemklassenpfad wird von der Laufzeit des Anwendungsclients nicht verwendet, wenn Sie den launchClient Batch- oder Shelldateien. In diesem Fall ist nicht der Systemklassenpfad die Ursache des Problems. Wenn die Klasse "launchClient" jedoch direkt geladen wird, muss der Systemklassenpfad ebenfalls durchsucht werden.

Fehler: com.ibm.websphere.naming.CannotInstantiateObjectException

Fehler: com.ibm.websphere.naming.CannotInstantiateObjectException: Exception occurred while attempting to get an instance of the object for the specified reference object. [Root exception is javax.naming.NameNotFoundException: xxxxxxxxxx]

Erläuterung	Mögliche Ursachen	Empfohlene Maßnahmen
Diese Ausnahme tritt ein, wenn die Suche nach einem Objekt erfolgt, das nicht auf dem Hostserver installiert ist. Ihr Programm kann den Namen im lokalen Client-Java Naming and Directory Interface (JNDI)-Namespace nachschlagen, erhielt aber eine NameNotFoundException Ausnahme, da es sich nicht auf dem Hostserver befindet. Ein typisches Beispiel ist das Suchen einer EJB-Komponente, die nicht auf dem Hostserver, auf den Sie zugreifen, installiert ist. Diese Ausnahme kann auch eintreten, wenn der im Anwendungsclientmodul konfigurierte JNDI-Name nicht dem tatsächlichen JNDI-Namen der Ressource auf dem Hostserver entspricht.	Der falsche Hostserver wurde aufgerufen Ressource wurde nicht definiert Ressource wurde nicht installiert Der Anwendungsserver wurde nicht gestartet JNDI-Konfiguration ist ungültig	Wenn Sie auf den falschen Hostserver zugreifen, müssen Sie den Befehl `launchClient` mit dem Parameter "-CCBootstrapHost" erneut ausführen und dabei den richtigen Namen des Hostservers angeben. Beim Zugriff auf den richtigen Hostserver müssen Sie das Befehlszeilentool `dumpnamespace` des Produkts ausführen, um eine Liste des JNDI-Namespace des Hostservers anzuzeigen. Wird der Name des fehlerhaften Objekts nicht angezeigt, ist die Ressource entweder nicht auf dem Hostserver installiert oder der entsprechende Anwendungsserver wurde nicht gestartet. Wird festgestellt, dass die Ressource bereits installiert ist und gestartet wurde, entspricht der JNDI-Name in der Clientanwendung nicht dem globalen JNDI-Namen auf dem Hostserver. Vergleichen Sie mithilfe eines Assembliertools den JNDI-Bindungswert des fehlerhaften Objekts in der Clientanwendung mit dem JNDI-Bindungswert des Objekts in der Anwendung des Hostservers. Diese Werte müssen übereinstimmen.

Fehler: javax.naming.ServiceUnavailableException

Fehler: javax.naming.ServiceUnavailableException: A communication failure occurred while attempting to obtain an initial context using the provider url: "iiop://[invalidhostname]". Stellen Sie sicher, dass die Host- und Portinformationen korrekt sind und dass auf dem mit der Provider-URL angegebenen Server ein Name-Server ausgeführt wird. Wurde keine Portnummer angegeben, wird die Standardportnummer 2809 verwendet. Andere mögliche Fehlerursachen liegen in der Konfiguration der Netzumgebung oder des Workstation-Netzes. Root exception is org.omg.CORBA.INTERNAL: JORB0050E: In Profile.getIPAddress(), InetAddress.getByName[invalidhostname] threw an UnknownHostException. minor code: 4942F5B6 completed: Maybe

Erläuterung	Mögliche Ursachen	Empfohlene Maßnahmen
Diese Ausnahme tritt ein, wenn ein ungültiger Hostservername angegeben wurde.	Der falsche Hostserver wurde aufgerufen Ungültiger Host-Server-Name	Führen Sie den Befehl `launchClient` erneut aus und geben Sie den richtigen Namen des Hostservers mit dem Parameter -CCBootstrapHost an.

Fehler: javax.naming.CommunicationException

Fehler: javax.naming.CommunicationException: Could not obtain an initial context due to a communication failure. Since no provider URL was specified, either the bootrap host and port of an existing ORB was used, or a new ORB instance was created and initialized with the default bootstrap host of "localhost" and the default bootstrap port of 2809. Make sure the ORB bootstrap host and port resolve to a running name server. Root exception is org.omg.CORBA.COMM_FAILURE: WRITE_ERROR_SEND_1 minor code: 49421050 completed: No

Erläuterung	Mögliche Ursachen	Empfohlene Maßnahmen
Diese Ausnahme tritt ein, wenn Sie den Befehl `launchClient` für einen Hostserver ausführen, für den der WebSphere Application Server nicht gestartet wurde. Diese Ausnahme wird auch ausgelöst, wenn Sie einen ungültigen Servernamen für den Host angeeben haben. Dies ist möglicherweise auch dann der Fall, wenn Sie bei der Ausführung des Tools launchClient keinen Servernamen angeben. Das Standardverhalten ist für die launchClient Tool auf dem lokalen Host auszuführen, weil WebSphere® Application Server kennt den Namen Ihres Hostservers nicht. Dieses Standardverhalten funktioniert nur, wenn Sie den Client auf demselben Computer ausführen wie WebSphere Application Server ist installiert.	Der falsche Hostserver wurde aufgerufen Ungültiger Host-Server-Name Ungültige Referenz auf localhost Der Anwendungsserver wurde nicht gestartet Ungültiger Bootstrap-Port	Falls Sie auf den falschen Hostserver zugegriffen haben, führen Sie den Befehl `launchClient` erneut aus und geben Sie mit dem Parameter `-CCBootstrapHost` den Namen des Hostservers an. Andernfalls starten Sie den Application Server auf dem Hostserver und führen den Befehl `launchClient` erneut aus.

Windows-Fehler: javax.naming.CommunicationException

Fehler: javax.naming.CommunicationException: Could not get the users matching the pattern wasuser6 because of the following exception javax.naming.CommunicationException: simple bind failed: server_location. Root exception is javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake.

Erläuterung	Mögliche Ursachen	Empfohlene Maßnahmen
Diese Ausnahme tritt auf, wenn Sie die Verwaltungs-, Anwendungs- und Java 2-Sicherheit mithilfe der LDAP-Benutzerregistry aktivieren.	In der Konfigurationsanzeige für die eigenständige LDAP-Registry wurde die Option SSL aktiviert ausgewählt. Die LDAP-Portnummer oder der Name des LDAP-Hosts ist falsch. Das LDAP-Serverzertifikat auf dem LDAP-Server ist ungültig oder abgelaufen. Die Zertifizierungsstelle (CA) wird nicht importiert in WebSphere Application Server, oder es ist falsch. Die SSL-Konfiguration (Secure Sockets Layer) ist ungültig. Es liegt ein Netzproblem vor.	Wählen Sie die Option SSL aktiviert ab und versuchen Sie erneut, die Verbindung herzustellen. Der SSL aktiviert Option gibt an, ob Verbindungen zwischen den WebSphere Application Server Plug-in und Anwendungsserver mit SSL. Die Standardeinstellung sieht vor, dass SSL nicht verwendet wird.

Fehler: javax.naming.NameNotFoundException

Fehler: javax.naming.NameNotFoundException: Name comp/env/ejb not found in context "java:"

Erläuterung	Mögliche Ursachen	Empfohlene Maßnahmen
Diese Ausnahme wird ausgelöst, wenn der Java-Code den angegebenen Namen im lokalen JNDI-Namespace nicht finden kann.	Keine Bindungsinformationen für den angegebenen Namen Falsche Bindungsinformationen für den angegebenen Namen Falscher Klassenlader zum Laden einer der Programmklassen verwendet Eine Ressourcenreferenz enthält keine Clientkonfigurationsdaten	Öffnen Sie die EAR-Datei mit einem Assembliertool und überprüfen Sie die Bindungen für den fehlerhaften Namen. Stellen Sie sicher, dass die Informationen korrekt sind. Wenn Sie Ressourcenreferenzen verwenden, öffnen Sie die EAR-Datei mit dem ACRCT (Application Client Resource Configuration Tool) und vergewissern Sie sich, dass die Ressourcenreferenz Clientkonfigurationsdaten enthält und der Name der Ressourcenreferenz genau mit dem JNDI-Namen der Clientkonfiguration übereinstimmt. Sind die Werte korrekt, liegt möglicherweise ein Fehler beim Klassenlader vor.

Fehler: java.lang.ClassCastException

Fehler: java.lang.ClassCastException: Unable to load class: org.omg.stub.WebSphereSamples.HelloEJB._HelloHome_Stub at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(portableRemoteObject.java:269)

Erläuterung	Mögliche Ursachen	Empfohlene Maßnahmen
Diese Ausnahme tritt ein, wenn das Anwendungsprogramm versucht, die EJB-Home-Klasse einzugrenzen und die Klassenlader die clientseitigen Bindungen der EJB nicht ermitteln können.	Die Dateien *_Stub.class und _Tie.class befinden sich nicht in der .jar-Datei der EJB Klassenlader konnte die Klassen nicht ermitteln	Sehen Sie sich die EJB-JAR-Datei in der EAR-Datei an und überprüfen Sie, ob die Klasse die clientseitigen Bindungen der Enterprise Java Beans (EJB) enthält. Hierbei handelt es sich um Klassendateien, deren Namen mit `_Stub` und `_Tie` enden. Falls die Bindungsklassen in der EJB-JAR-Datei enthalten sind, liegt möglicherweise ein Fehler beim Klassenlader vor.

Fehler: WSCL0210EError: java.lang.NoClassDefFoundError

Fehler: WSCL0210E: Das Enterprise-Archiv [Name_der_EAR-Datei] konnte nicht ermittelt werden. com.ibm.websphere.client.applicationclient.ClientContainerException: com.ibm.etools.archive.exception.OpenFailureException

Erläuterung	Mögliche Ursachen	Empfohlene Maßnahmen
Dieser Fehler tritt auf, wenn die Laufzeit des Anwendungsclients die EAR-Datei nicht lesen kann.	Die wahrscheinlichste Fehlerursache ist, dass das System die EAR-Datei in dem Pfad, der mit dem Befehl `launchClient` angegeben wurde, nicht ermitteln kann.	Vergewissern Sie sich, dass der Pfad und der Dateiname, der mit dem Befehl `launchclient` angegeben wurde, richtig sind. Wenn Sie das Windows-Betriebssystem verwenden und Pfad und Dateiname korrekt sind, verwenden Sie eine Kurzversion des Pfads und Dateinamens (8-stelliger Dateiname und 3-stellige Erweiterung).

Der Befehl "launchClient" scheint zu blockieren, und die Befehlszeile wird nicht Abschluss der Clientanwendung nicht angezeigt.

Erläuterung	Mögliche Ursachen	Empfohlene Maßnahmen
Wenn Sie Ihren Anwendungsclient mit dem`launchClient` befehligen Sie die WebSphere Application Server Zur Laufzeit muss möglicherweise der Sicherheitsanmeldedialog angezeigt werden. Um diesen Dialog anzuzeigen, WebSphere Application Server Zur Laufzeit wird ein Abstract Window Toolkit (AWT)-Thread erstellt. Wenn Ihre Anwendung von ihrer Hauptmethode zur Laufzeit des Anwendungsclients zurückkehrt, versucht die Laufzeit des Anwendungsclients, zum Betriebssystem zurückzukehren und den Code der Java Virtual Machine (JVM) zu beenden. Da jedoch ein AWT-Thread vorhanden ist, wird der JVM-Code erst beendet, wenn `System.exit` aufgerufen wird.	Der JVM-Code wird nicht beendet, weil ein AWT-Thread vorhanden ist. Java-Code erfordert, dass`System.exit()` aufgerufen werden, um AWT-Threads zu beenden.	Ändern Sie Ihre Anwendung so, dass `System.exit(0)` als letzte Anweisung aufgerufen wird. Verwenden Sie beim Aufrufen des Befehls `launchClient` den Parameter `-CCexitVM=true`.

IBM® Der Support verfügt über Dokumente und Tools, mit denen Sie Zeit beim Zusammentragen der zur Problemlösung erforderlichen Informationen sparen können. Bevor Sie einen Problembericht öffnen, lesen Sie die Support-Seite des Produkts: https://www.ibm.com/mysupport/s/topic/0TO500000001DQQGA2/websphere-application-server.