Tipps zur Fehlerbehebung bei Anwendungsclients

Dieser Leitfaden zur Fehlerbehebung enthält Debugging-Tipps, die Sie bei der Behebung von Fehlern unterstützen, die in Java EE-Anwendungsclients (Java Platform, Enterprise Edition) häufig auftreten. 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
Prüfen Sie, ob die angegebene Klasse in einer JAR-Datei (Java Archive), die in Ihrer EAR-Datei (Enterprise Archive) enthalten ist, 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:
  1. Öffnen Sie Ihre EAR-Datei mit einem Assembliertool und wählen Sie den Anwendungsclient aus.
  2. Fügen Sie die Namen der anderen JAR-Datei in der EAR-Datei dem Feld "Klassenpfad" hinzu.
Diese Ausnahme ist im Allgemeinen auf einen fehlenden EJB-Modulnamen im Feld "Klassenpfad" zurückzuführen.

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.

[z/OS]Alternativ können Sie das Tool Client Container Resource Configuration Scripting verwenden.

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.

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

[Windows]Das Trennzeichen ist ein Semikolon.

Tipp: Der Klassenpfad des Systems wird nicht von der Laufzeit des Anwendungsclients verwendet, wenn Sie die Stapel- oder Shell-Dateien von launchClient verwenden. 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 Host-Server installiert ist. Ihr Programm kann den Namen im JNDI-Namespace (Java Naming and Directory Interface) des lokalen Clients suchen, empfängt jedoch eine Ausnahme des Typs "NameNotFoundException", da das Objekt sich nicht auf dem Host-Server befindet. Ein typisches Beispiel ist das Suchen einer EJB-Komponente, die nicht auf dem Host-Server, 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 Host-Server entspricht.
  • Der falsche Host-Server 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 Host-Server zugreifen, müssen Sie den Befehl launchClient mit dem Parameter "-CCBootstrapHost" erneut ausführen und dabei den richtigen Namen des Host-Servers angeben. Beim Zugriff auf den richtigen Host-Server müssen Sie das Befehlszeilentool dumpnamespace des Produkts ausführen, um eine Liste des JNDI-Namespace des Host-Servers anzuzeigen. Wird der Name des fehlerhaften Objekts nicht angezeigt, ist die Ressource entweder nicht auf dem Host-Server 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 Host-Server. Vergleichen Sie mithilfe eines Assembliertools den JNDI-Bindungswert des fehlerhaften Objekts in der Clientanwendung mit dem JNDI-Bindungswert des Objekts in der Anwendung des Host-Servers. 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]". Make sure that the host and port information is correct and that the server identified by the provider URL is a running name server. If no port number is specified, the default port number 2809 is used. Other possible causes include the network environment or workstation network configuration. 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 Host-Server-Name angegeben wurde.
  • Der falsche Host-Server wurde aufgerufen
  • Ungültiger Host-Server-Name
Führen Sie den Befehl launchClient erneut aus und geben Sie den richtigen Namen des Host-Servers 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 Host-Server 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. Standardmäßig wird das Tool "launchClient" auf dem lokalen Host ausgeführt, weil WebSphere Application Server den Namen Ihres Host-Servers nicht kennt. Dieses Standardverhalten ist nur möglich, wenn Sie den Client auf der Maschine ausführen, auf der auch WebSphere Application Server installiert ist.
  • Der falsche Host-Server 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 Host-Server zugegriffen haben, führen Sie den Befehl launchClient erneut aus und geben Sie mit dem Parameter -CCBootstrapHost den Namen des Host-Servers an. Andernfalls starten Sie den Application Server auf dem Host-Server 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 ein, wenn Sie die Verwaltungs-, Anwendungs- und Java-2-Sicherheit über die LDAP-Benutzerregistry aktivieren. Der Deployment Manager wird zwar erfolgreich erneut gestartet, aber Sie können sich nicht an der Administrationskonsole anmelden. Die Fehlernachricht wird in der Datei "SystemOut.log" aufgezeichnet.
  • 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) wurde nicht in WebSphere Application Server importiert oder sie ist ungültig.
  • 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. Die Option "SSL aktiviert" gibt an, ob Verbindungen zwischen dem WAS-Plug-in und dem Anwendungsserver mit SSL geschützt werden sollen. 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 lokalisieren 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
  • Ein Client-Container im Deployment Manager versucht, Enterprise-Erweiterungen zu verwenden (nicht unterstützt).

Ö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
Prüfen Sie die JAR-Datei der EJB, die sich in der EAR-Datei befindet, und vergewissern Sie sich, dass die Klasse die clientseitigen EJB-Bindungen 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.

[Windows]Wenn Sie mit dem Betriebssystem Windows arbeiten und Pfad und Dateiname richtig angegeben sind, kürzen Sie Pfad und Dateinamen ab (Dateiname mit 8 Zeichen und Erweiterung mit 3 Zeichen).

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

Erläuterung Mögliche Ursachen Empfohlene Maßnahmen
Wenn Sie den Anwendungsclient mit dem Befehl launchClient ausführen, muss die Laufzeit von WebSphere Application Server möglicherweise den Dialog für die Sicherheitsanmeldung anzeigen. Zum Anzeigen dieses Dialogs erstellt die Laufzeit von WebSphere Application Server einen AWT-Thread (Abstract Window Toolkit). Wenn die Anwendung von der Hauptmethode (main) zur Laufzeitumgebung des Anwendungsclients zurückkehrt, versucht die Laufzeitumgebung des Anwendungsclients, zum Betriebssystem zurückzukehren und den JVM-Code (Java Virtual Machine) 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. Beim Java-Code muss System.exit() aufgerufen werden, damit AWT-Threads beendet werden können.
  • Ä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.
[Windows]

Der Applet Client kann in Internet Explorer keinen HTML-Browser starten

Erläuterung Mögliche Ursachen Empfohlene Maßnahmen
Applet-Client-Anwendungen können nur auf Windows-Systemen ausgeführt werden. Bei der Ausführung der Applet-Client-Anwendung werden die Ausgabedaten der Anwendung in einem Browserfenster angezeigt. Wenn Sie Internet Explorer und das Betriebssystem Windows XP mit Service Pack 2 verwenden, können beim Anzeigen der Ausgabedaten Fehler auftreten. Das Betriebssystem Windows XP mit Service Pack 2 besitzt ein Sicherheitsfeature, das die Anzeige von Popup-Browserfenstern blockiert.
  • Suchen Sie in Internet Explorer im blockierten Popup-Browserfenster die Informationsleiste unterhalb der URL-Adressleiste.
  • Klicken Sie auf die Informationsleiste, um die Optionen anzuzeigen, mit denen Sie das Sicherheitsfeature des Betriebssystems inaktivieren können.
  • Wählen Sie die Option Blockierten Inhalt zulassen aus. Sie werden in einem Sicherheitsfenster aufgefordert, Ihre Auswahl zum Anzeigen des blockierten Inhalts zu bestätigen.
  • Klicken Sie auf Ja.
  • Die Applet-Clientanwendung wird ordnungsgemäß ausgeführt, und die Browserinformationen werden korrekt angezeigt.
Der IBM® Support besitzt Dokumente, mit denen Sie Zeit bei der Erfassung der für die Lösung des Problems erforderlichen Informationen einsparen können. Bevor Sie einen Fehlerbericht öffnen, sollten Sie sich die folgende Seite des IBM Support ansehen:

Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rcli_troubleshoot
Dateiname:rcli_troubleshoot.html