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. |
|
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.HelloHomeVergewissern 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. |
- Ö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.
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.
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.
Das Trennzeichen ist ein Doppelpunkt.
Das Trennzeichen ist ein Semikolon.
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. |
|
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. |
|
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. |
|
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]](../images/windows.gif)
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. |
|
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. |
|
Ö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. |
|
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.
|
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. |
|
![[Windows]](../images/windows.gif)
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. |
|