Probleme beim Anwendungszugriff

Zur Behebung der Fehler, die auftreten, wenn ein Servlet, eine JSP-Datei, eine eigenständige Anwendung oder ein anderer Client versucht, auf eine Enterprise-Bean, einen Verbindungspool oder ein anderes benanntes Objekt in WebSphere Application Server zuzugreifen, müssen Sie zunächst prüfen, ob über den Client auf den Zielserver zugegriffen werden kann.

Gehen Sie wie folgt vor:
  • Geben Sie in einer Befehlszeile auf dem Server des Clients ping Servername ein, und überprüfen Sie die Konnektivität.
  • In der Administrationskonsole des WebSphere Application Server können Sie prüfen, ob der Anwendungsserver der Zielressource, und ggf. das EJB-Modul oder Webmodul gestartet wird.

Fahren Sie nur fort, wenn kein Problem mit der Konnektivität vorliegt und die Zielressource scheinbar ausgeführt wird.

Wenn der angezeigte Fehler nicht in ähnlicher Form dokumentiert ist oder wenn Sie den Fehler anhand der bereitgestellten Informationen nicht beheben können, wenden Sie sich an die IBM® Unterstützungsfunktion.

NameNotFoundException bei JNDI-Lookup-Operation

Es gibt drei Ursachen für eine Ausnahme des Typs NameNotFoundException:

Falscher Lookup-Name
Wenn Sie die Ausnahme a NameNotFoundException beim Versuch, auf eine Enterprise-Bean, Datenquelle, Messaging-Ressource oder andere Ressource zuzugreifen, empfangen, gehen Sie wie folgt vor:
  1. Bestimmen Sie die Ursache für die Ausnahme NameNotFoundException.

    Durchsuchen Sie in der Administrationskonsole die Eigenschaften des Zielobjekts, und stellen Sie sicher, dass der JNDI-Name, den es angibt, mit dem JNDI-Namen, den der Client verwendet, übereinstimmt.

    Wenn Sie ein Objekt lokalisieren, das sich nicht auf dem Server befindet, von dem der Ausgangskontext abgerufen wurde, müssen Sie den vollständig qualifizierten Namen angeben.
    • Wenn der Zugriff über ein anderes Serverobjekt erfolgt, wenn z. B. ein Servlet auf eine Enterprise-Bean zugreift und Sie den Standardkontext verwenden, ohne den vollständig qualifizierten JNDI-Namen anzugeben, empfangen sie möglicherweise eine Ausnahme des Typs a NameNotFoundException, wenn sich das Objekt auf einem anderen Server befindet.
    • Erfolgt der Zugriff über einen eigenständigen Client, liegt dies möglicherweise daran, dass das Objekt, auf das Sie zuzugreifen versuchen, sich auf einem anderen Server als dem Server befindet, von dem Sie den Ausgangskontext abgerufen haben.
  2. Verwenden Sie den vollständig qualifizierten JNDI-Namen, um das Problem zu beheben.
    Wenn sich das Objekt in einem einzelnen Server befindet, lautet der vollständig qualifizierte JNDI-Namen wie folgt:
    cell/nodes/Knotenname/servers/Servername/JNDI-Name
    Einschränkung: Objekte werden in diesem Release nicht unterstützt.
    Wenn sich das Objekt in einem Server-Cluster befindet, lautet der vollständig qualifizierte JNDI-Namen wie folgt:
    cell/clusters/Clustername/JNDI-Name
Das gesuchte Objekte ist nicht gebunden
Gehen Sie wie folgt vor, um einen Fehler des Typs NameNotFoundException zu beheben, der ausgegeben wird, wenn das gesuchte Objekt nicht gebunden ist:
  1. Wenn das gesuchte Objekt ein Anwendungsobjekt ist, z. B. eine Enterprise-Bean, vergewissern Sie sich, dass die Anwendung aktiv ist.
  2. Führen Sie das Tool dumpNameSpace aus, um den Inhalt des Namespace anzuzeigen und zu prüfen, ob das gesuchte Objekte unter dem erwarteten Namen an den Namespace gebunden ist.
Es werden zwei Server mit demselben Namen auf demselben Host ausgeführt, die interagieren sollen.
Wenn beispielsweise eine Anwendung, die auf einem Server auf dem Knoten node1 ausgeführt wird, eine Referenz auf ein fernes Objekt verwendet, das sich auf einem Server mit ähnlichem Namen auf dem Knoten node2 befindet, und beide Knoten auf demselben Host installiert sind, können verschiedene Fehler auftreten:
  • JNDI-Lookup-Operationen schlagen mit einer Ausnahme des Typs NameNotFoundException fehl.
  • Objektreferenzen, die über andere Methoden als JNDI-Lookup-Operationen abgerufen werden, scheitern wahrscheinlich mit einer Ausnahme des Typs org.omg.CORBA.OBJECT_NOT_EXIST.
  • Eine Referenz auf ein fernes Objekt wird fälschlicherweise in ein Objekt im lokalen Prozess aufgelöst, da das Objekt auch im lokalen Prozess vorhanden ist, d. h., eine Referenz auf ein fernes Objekt im Serverprozess auf dem Knoten "node2" wird fälschlicherweise in denselben Objekttyp im lokalen Prozess aufgelöst, bei dem es sich um den Serverprozess auf dem Knoten "node1" handelt.

Objektreferenzen zwischen Servern auf unterschiedlichen Knoten und unterschiedlichen Hosts lösen selbst dann keine Ausnahme aus, wenn die Servernamen nicht eindeutig sind.

Setzen Sie zur Behebung der Fehler eine angepasste JVM-Eigenschaft für den Object Request Broker (ORB), com.ibm.websphere.orb.uniqueServerName, für einen oder beide Server auf true:
  1. Klicken Sie in der Administrationskonsole auf Server > Servertypen > WebSphere-Anwendungsserver > Servername > Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine > Angepasste Eigenschaften > Neu.
  2. Definieren Sie auf der Seite "Angepasste Eigenschaften" die angepasste Eigenschaft:
    1. Geben Sie im Feld Name Folgendes ein: com.ibm.websphere.orb.uniqueServerName.
    2. Geben Sie im Feld Wert Folgendes ein: true.
  3. Klicken Sie auf OK.
  4. Klicken Sie in der Taskleiste der Konsole auf Speichern.
  5. Starten Sie den Anwendungsserver erneut.

Zur Vermeidung ähnlicher Fehler mit dem Node Agent können Sie die angepasste JVM-Eigenschaft des Node Agent, com.ibm.websphere.orb.uniqueServerName, auf true setzen.

CannotInstantiateObjectException bei JNDI-Lookup-Operation

Wenn Sie diese Ausnahme beim Versuch, auf eine Enterprise-Bean, Datenquelle, Messaging-Ressource oder andere Ressource zuzugreifen, empfangen, sind die möglichen Fehlerursachen folgende:
  • Ein serialisiertes Java-Objekt wird lokalisiert, die Klassen, die zu seiner Entserialisierung erforderlich sind, befinden sich jedoch nicht in der Laufzeitumgebung.
  • Ein Referenzobjekt wird lokalisiert, und die zugeordnete Factory, die als Teil des Lookup-Prozesses für seine Verarbeitung verwendet wird, ist fehlerhaft.
Gehen Sie wie folgt vor, um die Fehlerursache zu bestimmen:
  • Suchen Sie in den entsprechenden Protokollen nach Ausnahmen, die der CannotInstantiateObjektException unmittelbar vorangehen. Wenn es sich um eine Ausnahme des Typs "java.lang.NoClassDefFoundError" oder "java.lang.ClassNotFoundException" handelt, stellen Sie sicher, dass die in der Fehlernachricht referenzierte Klasse vom Klassenladeprogramm gefunden werden kann..

    [AIX][Linux][HP-UX][Solaris][Windows][IBM i]Sehen Sie sich die JVM-Protokolle an.

    [z/OS]Untersuchen Sie die Protokolle des Servers, der die Zielressource enthält.

  • Geben Sie den Stack-Trace für die Fehlerursache aus, und suchen Sie nach der Factory-Klasse. Die Klasse wird von javax.naming.NamingManager.getObjectInstance() aufgerufen. Die Ursache für den Fehler ist von der Factory-Implementierung abhängig, und möglicherweise müssen Sie sich an den Entwickler der Factory-Klasse wenden.

Nachricht NMSV0610I erscheint in der Protokolldatei des Servers und zeigt an, dass eine Naming-Ausnahme eingetreten ist

Diese Fehlernachricht dient nur Informationszwecken und wird angezeigt, wenn die Ausnahme sich auf einen tatsächlichen Fehler bezieht. In den meisten Fällen trifft dies nicht zu. Trifft dies zu, muss die Datei benachbarte Einträge für Kontext enthalten.

  • Treten keine Probleme auf, ignorieren Sie diese Nachricht. Ignorieren Sie die Nachricht auch, wenn der auftretende Fehler sich scheinbar nicht auf die angezeigte Ausnahme bezieht und keine anderen benachbarten Fehlernachrichten im Protokoll vorhanden sind.
  • Tritt ein Fehler auf, suchen Sie im Protokoll nach zugrunde liegenden Fehlernachrichten.
  • Die Informationen in der Nachricht NMSV0610I kann wertvolle Debug-Daten für andere benachbarte Fehlernachrichten enthalten, die als Reaktion auf die aufgetretene Ausnahme gesendet werden.

OperationNotSupportedException bei JNDI-Kontextoperation

Für diesen Fehler gibt es zwei mögliche Ursachen:
  • Eine Aktualisierungsoperation, wie z. B. die Operation "bind", wird mit einem mit "java:comp/env" beginnenden Namen ausgeführt. Dieser Kontext und seine Subkontexte sind schreibgeschützte Kontexte (Read-Only).
  • Die Kontextoperation "bind" oder "rebind" eines Nicht-CORBA-Objekts wird für einen fernen Namespace, der nicht zum Produkt gehört, ausgeführt. Nur CORBA-Objekte können an diese CosNaming-Namespaces gebunden werden.

Prüfen Sie die vollständige Ausnahmenachricht, um festzustellen, welcher dieser Fehler das Problem verursacht.

WSVR0046E: ejb/jndiName kann nicht gebunden werden: ejb/jndiName. Ursprüngliche Ausnahme: org.omg.CosNaming.NamingContextPackage.AlreadyBound

Dieser Fehler tritt auf, wenn zwei Enterprise-Bean-Serveranwendungen auf demselben Server installiert wurden, sodass in der Bindung ein Namenskonflikt aufgetreten ist. Das bedeutet, dass ein JNDI-Namenswert in den Implementierungsdeskriptoren der zwei Anwendungen identisch ist. Der Fehler tritt während des Serverstarts auf, wenn die zweite Anwendung, die diesen JNDI-Namenswert verwendet, gestartet wird.

Wenn Sie sich vergewissern möchten, dass dieser Fehler vorliegt, prüfen Sie die Implementierungsdeskriptoren für alle Enterprise-Bean-Serveranwendungen, die auf dem Server ausgeführt werden, um nach einem JNDI-Namen, der in mehreren Enterprise-Bean-Anwendungen angegeben ist, zu suchen.

Zur Behebung dieses Fehlers müssen Sie die doppelten JNDI-Namenswerte ändern, um sicherzustellen, dass jede Enterprise-Bean im Serverprozess an einen anderen Namen gebunden ist.

ConfigurationException bei Operation "new InitialContext" oder bei einer JNDI-Kontextoperation mit einem URL-Namen

Wenn Sie versuchen, einen JNDI-Ausgangskontext abzurufen, kann eine konfigurationsbedingte Ausnahme eintreten, weil ein ungültiger Wert einer JNDI-Eigenschaft an den InitialContext-Konstruktor übergeben wurde. Das beinhaltet JNDI-Eigenschaften, die in den Systemeigenschaften oder in einer für den aktiven Klassenlader erkennbaren jndi.properties-Datei definiert sind. Die Eigenschaft mit der höchsten Fehlerwahrscheinlichkeit ist ein Provider-URL, der im falschen Format angegeben wurde. Wenn der JNDI-Client als Thin Client ausgeführt wird, d. h. wenn die Variable CLASSPATH so definiert ist, dass sie alle einzelnen JAR-Dateien enthält, vergewissern Sie sich, dass die .jar-Datei, die die Eigenschaftendatei com/ibm/websphere/naming/jndiprovider.properties enthält, in der Variable CLASSPATH angegeben ist.

Wenn die Ausnahme beim Aufruf eines JNDI-Kontextes auftritt und dabei ein Name in Form eines URL angegeben ist, ist die aktuelle JNDI-Konfiguration möglicherweise nicht ordnungsgemäß konfiguriert, sodass der erforderliche Factory-Klassenname nicht bestimmt werden kann oder die Factory für den gegenwärtig aktiven Klassenlader möglicherweise nicht erkennbar ist. Wenn der Name ein URL des Typs "Java:" ist, muss der JNDI-Client in einer Java EE-Client- oder -Serverumgebung ausgeführt werden. Das bedeutet, der Client muss in einem Container ausgeführt werden.

Überprüfen Sie die Ausnahmenachricht, die zu diesem Fehler geführt hat.

Wenn die Ausnahmenachricht vom InitialContext-Konstruktor ausgelöst wird, korrigieren Sie die Eigenschaftseinstellung oder die Variable CLASSPATH.

Wenn die Ausnahme von einer JNDI-Kontextmethode ausgelöst wird, vergewissern Sie sich, dass die Eigenschaft java.naming.factory.url.pkgs den Paketnamen für die Factory, die für das URL-Schema im Namen erforderlich ist, enthält. URL-Namen mit dem Java-Schema können nur verwendet werden, wenn sie in einem Container ausgeführt werden.

ServiceUnavailableException bei Operation "new InitialContext".

Dies Ausnahme zeigt an, dass beim Versuch, auf den Namensserver zuzugreifen und einen Ausgangskontext abzurufen, ein unerwartetes Problem aufgetreten ist. Sie können die eigentliche Fehlerursache der ServiceUnavailableException abfragen. Die Angaben zur Fehlerursache enthalten weitere Informationen. Es ist möglich, dass einige der Probleme, die für CommunicationExceptions beschrieben werden, ebenfalls zu einer ServiceUnavailableException führen.

Da diese Ausnahme von einem unerwarteten Fehler ausgelöst wird, gibt es keine mögliche Fehlerursache, die zu bestätigen ist. Wenn die ursprüngliche Ausnahme die Fehlerursache nicht angibt, prüfen Sie die möglichen Fehlerursachen, die für CommunicationExceptions aufgeführt sind.

CommunicationException bei Operation "new InitialContext" ausgelöst

Zu dem vom Provider-URL angegebenen Namensserver kann keine Verbindung hergestellt werden, um den JNDI-Ausgangskontext abzurufen. Es gibt viele mögliche Ursachen für diesen Fehlerursachen:
  • Der im Provider-URL angegebene Hostname oder Port ist falsch.
  • Der Hostname kann vom Domänennamensserver nicht in eine IP-Adresse aufgelöst werden oder die IP-Adresse stimmt nicht mit der IP-Adresse überein, unter der der Server tatsächlich ausgeführt wird.
  • Eine Firewall auf dem Client oder dem Server verhindert, dass der im Provider-URL angegebene Port verwendet wird.
Gehen Sie wie folgt vor, um diesen Fehler zu beheben:
  • Vergewissern Sie sich, dass die Provider-URL- und die Netzkonfiguration auf der Client- und der Servermaschine richtig sind.
  • Vergewissern Sie sich, dass der Hostname in eine IP-Adresse aufgelöst werden kann, auf die die Clientmaschine Zugriff hat. Dazu können Sie den Befehl "ping" verwenden.
  • Wenn Sie eine Firewall ausführen, vergewissern Sie sich, dass der im Provider-URL angegebene Port verwendet werden kann.

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=rtrb_namingprobs
Dateiname:rtrb_namingprobs.html