Tipps zur Fehlerbehebung für Liberty

In den Fehlerbehebungsinformationen werden Lösungen für häufig auftretendes Probleme beschrieben.

Zur Unterstützung beim Ermitteln und Beheben von Fehlern stellt das Produkt eine einheitliche Protokollierungskomponente bereit. Weitere Informationen hierzu finden Sie unter Protokollierung und Traceerstellung.

Wenn Sie eine Ausnahmenachricht empfangen, finden Sie unter Liberty: Nachrichten Informationen zu dieser Nachricht.

Die Java™-API-Dokumentation für die einzelnen Liberty-APIs finden Sie in einer eigenständigen .zip-Datei in einer der Javadoc-Unterverzeichnisse des Verzeichnisses ${wlp.install.dir}/dev.

Für verteilte PlattformenNähere Informationen zu den bekannten Einschränkungen bei Verwendung von Liberty finden Sie in den folgenden Abschnitten:

Für IBM i-PlattformenNähere Informationen zu den bekannten Einschränkungen, die bei der Verwendung von Liberty gelten, finden Sie unter Bekannte Probleme und Einschränkungen für die Laufzeitumgebung.

Prüfen Sie, ob die JDKs eine unterstützte Version haben

Wenn Fehler auftreten, für die keine einfache Erklärung zu finden ist, prüfen Sie, ob die JDKs, die Sie verwenden, mit Java Version 7 oder höher kompatibel sind und einen aktuellen Service-Level haben. Weitere Informationen hierzu finden Sie unter Unterstützte Java-Mindestversionen.

Fehlerbehebung für die Sicherheit

In diesem Abschnitt werden einige häufige Sicherheitsprobleme und auswählbare Lösungen beschrieben.

SESN0008E: Ein als anonym authentifizierter Benutzer hat versucht, auf eine Sitzung zuzugreifen, deren Eigner user:LdapRegistry/cn=steven,o=myCompany,c=US ist.
Dieser Fehler tritt auf, wenn ein nicht authentifizierter Benutzer versucht, auf eine von einem authentifizierten Benutzer erstellte Sitzung zuzugreifen. Die Sitzungssicherheit, die standardmäßig aktiviert ist, verhindert den unbefugten Zugriff auf die Sitzungen. Nur der Benutzer, der eine Sitzung erstellt hat, kann auf die Sitzung zugreifen. Weitere Informationen finden Sie unter Unterstützung der Sicherheit von Sitzungen.

Dieser Fehler kann auftreten, wenn Sie eine JSP (z. B. login.jsp) für Ihre formularbasierte Anmeldung verwenden und das vom Browser gesendete SSO-Token abgelaufen ist. Da das SSO-Token abgelaufen ist, wird der Benutzer aufgefordert, die Anmeldung über die Seite login.jsp, die für die formularbasierte Anmeldung konfiguriert ist, zu wiederholen. Die JSP-Seite versucht standardmäßig, eine Sitzung abzurufen. Diese Sitzung wurde ursprünglich von dem Benutzer erstellt, dessen Token abgelaufen ist. Da das Token ist abgelaufen und der Benutzer nicht authentifiziert ist, werden werden keine Berechtigungsnachweise beim Zugriff auf diese Sitzung bereitgestellt. Deshalb tritt dieser Fehler auf.

Sie können diesen Fehler vermeiden, indem Sie den Browser, der eine neue Sitzung startet, erneut starten oder die Datei login.jsp so konfigurieren, dass standardmäßig keine Sitzung erstellt wird. Wenn Sie sich für die Aktualisierung der Datei login.jsp entscheiden, legen Sie <%@ page session="false" %> fest.

CWWKS9104A: Die Berechtigung für den Benutzer {0} ist beim Aufruf von {1} in {2} fehlgeschlagen. Dem Benutzer wurde kein Zugriff auf die erforderlichen Rollen erteilt: {3}.
Dieser Fehler tritt auf, wenn Sie für die Rollen, die die Anwendung erfordert, nicht berechtigt sind. Stellen Sie sicher, dass der Benutzer oder die Gruppe, zu der der Benutzer gehört, mindestens einer der Rollen zugeordnet ist, die in der Fehlernachricht genannt sind. Eine Benutzer/Rolle-Zuordnung, die in der Datei ibm-application-bnd.xmi/xml definiert ist, hat Vorrang vor einer Zuordnung, die in der Datei server.xml definiert ist. Überprüfen Sie beide Ressourcen, um sicherzustellen, dass die korrekte Zuordnung definiert ist. Weitere Informationen hierzu finden Sie unter Berechtigung für Anwendungen in Liberty konfigurieren.
CWWKS9104A: Die Berechtigung für den Benutzer {0} ist fehlgeschlagen.
Dieser Fehler kann auftreten, wenn Sie application und webApplication für dasselbe Kontextstammverzeichnis angeben. Kommt es zu einem Konflikt, wird die neueste definierte Konfiguration ignoriert und dies führt zu einem unerwarteten Fehler, wie z. B. CWWKS9104A.
Es ist nicht möglich, zwei Anwendungen mit dem Namen {0} zu starten. Die Folge sind ein nicht erwartetes Sicherheitsverhalten und Fehlernachrichten wie beispielsweise CWWKS9104A.
Dieser Fehler tritt auf, wenn Sie Ihre Anwendung sowohl in der Datei server.xml mit dem Element application als auch im Ordner dropins angeben. Deshalb wird versucht die Anwendung zweimal zu installieren und die Sicherheitskonfiguration in der Datei server.xml wird aktiv oder nicht. Entfernen Sie die Anwendung aus dem Ordner dropins und kopieren Sie die Anwendung in ein anderes Verzeichnis, um diesen Fehler zu beheben. Wenn Sie die Anwendung im Ordner dropins beibehalten müssen, müssen Sie die Anwendungsüberwachung inaktivieren, indem Sie Folgendes in der Datei server.xml festlegen:
<applicationMonitor dropinsEnabled="false"/>
Ein nicht authentifizierter Benutzer konnte auf mein Servlet oder meine JSP zugreifen
Ein Benutzer mit dem Principal UNAUTHENTICATED (oder der nicht authentifizierte SAF-Benutzer unter z/OS) wird erstellt, wenn die Authentifizierung fehlschlägt oder wenn Ihr Servlet oder Ihre JSP nicht geschützt ist. Ein nicht authentifizierter Benutzer kann auf Ihr Servlet oder Ihre JSP zugreifen, wenn Sie keine Integritätsbedingungen für die Sicherheit definieren oder wenn Sie die für Ihre Anwendung erforderliche Rolle dem Sondersubjekt EVERYONE zuordnen. Überprüfen Sie die Benutzer/Rolle-Zuordnungen in den Dateien ibm-application-bnd.xmi/xml und server.xml. Gehen Sie wie folgt vor:
  • Wenn Ihr Servlet oder Ihre JSP nicht geschützt ist, fügen Sie dem Implementierungsdeskriptor Ihrer Anwendung Integritätsbedingungen für die Sicherheit hinzu. Informationen hierzu finden Sie unter Authentifizierung.
  • Wenn Sie nicht möchten, dass nicht authentifizierte Benutzer auf Ihre Anwendung zugreifen, entfernen Sie das Sondersubjekt EVERYONE aus der Zuordnung für diese Rolle. Weitere Informationen hierzu finden Sie unter Berechtigung für Anwendungen in Liberty konfigurieren.
  • Wenn ein bestimmter Benutzer nicht für Ihr Servlet oder Ihre JSP berechtigt werden kann, prüfen Sie, wer dieser Rolle zugeordnet ist, indem Sie die Dateien ibm-application-bnd.xmi/xml und server.xml untersuchen. Sie können eine Rolle einem Benutzer, einer Gruppe oder einem Sondersubjekt zuordnen. Wenn Ihre Rolle dem Sondersubjekt EVERYONE zugeordnet ist, wird jedem Benutzer der Zugriff gewährt. Wenn Ihre Rolle dem Sondersubjekt ALL_AUTHENTICATED zugeordnet ist, wird jedem authentifizierten Benutzer der Zugriff gewährt. Entfernen Sie diese Sondersubjekte, wenn Sie den Zugriff auf Ihr Servlet bzw. Ihre JSP weiter einschränken möchten. Prüfen Sie abschließend, zu welcher Gruppe der Benutzer gehört. Obwohl der Benutzer möglicherweise keinen expliziten Zugriff hat, ist seine Gruppe möglicherweise der Rolle zugeordnet. In diesem Fall entfernen Sie den Benutzer aus der berechtigten Gruppe oder die Gruppe aus der Rollenzuordnung. Weitere Informationen hierzu finden Sie unter Berechtigung für Anwendungen in Liberty konfigurieren.
Single Sign-on (SSO) funktioniert nicht
Wenn SSO nicht funktioniert, vergewissern Sie sich, dass die verschiedenen Liberty-Server, die dieselben LTPA-Schlüssel, dasselbe Kennwort und dasselbe ssoCookieName-Attribut des Elements webAppSecurity verwenden, auch dieselbe UTC-Zeit und dieselbe Benutzerregistry verwenden. Wenn das Token abgelaufen ist oder das Cookie über einen Web-Browser gesendet wird, nachdem die Benutzerregistry auf inkonsistente Weise geändert wurde (z. B. Änderung des Realms oder Entfernen des Benutzers, der vom Cookie dargestellt wird) schlägt SSO fehl und der Benutzer wird aufgefordert, die Berechtigungsnachweisinformationen erneut einzugeben. Weitere Informationen hierzu finden Sie unter SSO-Konfiguration mit LTPA-Cookies in Liberty anpassen.
Debugging öffentlicher Sicherheits-APIs
WSSecurityHelper und RegistryHelper werden geladen, selbst wenn die Sicherheit nicht aktiviert ist, z. B., wenn kein Sicherheitsfeature (appSecurity-1.0, appSecurity-2.0 oder zosSecurity-1.0) angegeben ist. Wenn die Sicherheit nicht aktiviert ist, geben die Methoden WSSecurityHelper.isServerSecurityEnabled() und WSSecurityHelper.isGlobalSecurityEnabled() beide "false" zurück und die Methode RegistryHelper.getUserRegistry() gibt null zurück.

Andere öffentliche Sicherheits-API-Klassen werden unter Umständen nicht geladen, wenn die Sicherheit nicht aktiviert ist. Wenn Sie versuchen, auf diese Klassen zuzugreifen und eine Methode in der Klasse aufrufen, kann eine Ausnahme des Typs java.lang.NoClassDefFoundError eintreten.

Um Ausnahmen des Typs java.lang.NoClassDefFoundError zu vermeiden, müssen Sie zuerst prüfen, ob die Sicherheit aktiviert ist, indem Sie die Klasse WSSecurityHelper.isServerSecurityEnabled() oder WSSecurityHelper.isGlobalSecurityEnabled() aufrufen. Rufen Sie weitere öffentliche Sicherheits-API-Klassen nur dann auf, wenn die Sicherheit aktiviert ist. Beispiele für diese Codierungstechnik finden Sie unter Öffentliche Sicherheits-APIs in Liberty.

Anmerkung: Dieses Verhalten weicht von dem in WebSphere Application Server Traditional ab. In WebSphere Application Server Traditional werden immer alle Klassen geladen, unabhängig davon, ob die Sicherheit aktiviert ist.
Benutzer mit Unicode-Zeichen können nicht authentifiziert werden
Wenn Sie Benutzer authentifizieren möchten, deren Namen Unicode-Zeichen enthalten, müssen Sie den Zeichencodierungstyp, der vom Liberty-Server verwendet wird, auf UTF-8 setzen, indem Sie die folgende JVM-Option dem Serverstartbefehl hinzufügen:
-Dclient.encoding.override=UTF-8
Außerdem müssen Sie charset und pageEncoding auf Ihrer Anmeldeseite angeben. Nachfolgend sehen Sie ein Beispiel für die Angabe dieser Parameter auf einer JSP-Anmeldeseite:
<%@page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
java.lang.annotation.AnnotationFormatError: java.lang.IllegalArgumentException:Wrong type at constant pool index at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:87)
Dieser Fehler kann auftreten, wenn ein OpenID Connect- oder OAuth-Provider einen Datenbankspeicher für die Clientregistrierung mit einer JDK 7-Version verwendet.

Sie können dieses Problem vermeiden, indem Sie ein Upgrade auf JDK Version 7.1 durchführen.

Fehlerbehebung für LDAP

In diesem Abschnitt werden einige häufige LDAP-Probleme und auswählbare Lösungen beschrieben.

FFDC1015I: An FFDC Incident has been created: javax.naming.ServiceUnavailableException: myldapserver.mycompany.com:636; socket closed com.ibm.ws.security.registry.ldap.internal.LdapRegistry 298
Diese Nachricht in der Datei messages.log zeigt an, dass der konfigurierte LDAP-Server nicht erreicht werden kann. Stellen Sie sicher, dass Ihr LDAP-Server aktiv ist und ein Zugriff auf die zugehörige IP-Adresse vom Liberty-Server möglich ist.
The javax.naming.CommunicationException: simple bind failed: myldapserver.mycompany.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.g: PKIX path building failed: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target]
Wenn Sie SSL auf Ihrem LDAP-Server aktivieren, ohne de Unterzeichner des LDAP-Servers in den Truststore zu kopieren, der über das Element LDAPSSLSettings referenziert wird, schlägt eine Verbindung zum LDAP-Server mit einem SSL-Handshake-Fehler fehl. Stellen Sie sicher, dass der Unterzeichner des LDAP-Servers in Ihren Truststore kopiert wird.
The javax.naming.CommunicationException: myldapserver.mycompany.com:389 [Root exception is java.net.BindException: Address already in use: connect]
Diese Nachricht wird möglicherweise in den FFDC-Protokollen angezeigt und gibt an, dass die verwendbaren Sockets im lokalen Server ausgeschöpft sind. Dies kann zu einem Fehler führen, wenn Sie eine Verbindung zu Ihrem LDAP-Server herstellen. Vergewissern Sie sich, dass das Socket nicht verwendet wird und versuchen Sie es erneut.
CWWKS1100A: Die Authentifizierung für die Benutzer-ID xxxxx war nicht erfolgreich. Es wurde eine ungültige Benutzer-ID und/oder ein ungültiges Kennwort angegeben.
Diese FFDC-Ausnahme tritt möglicherweise bei Lastspitzen im Server auf, obwohl der in der Nachricht genannte Benutzer im LDAP-Server als gültiger Benutzer definiert ist. In der LDAP-Konfiguration können Sie die Eigenschaft reuseConnection=false hinzufügen oder diese mit den Entwicklertools inaktivieren. Legen Sie für diese Eigenschaft den Standardwert true fest, um dieses Problem zu beheben.

Fehlerbehebung für SSL

In diesem Abschnitt werden einige allgemeine SSL-Probleme und auswählbare Lösungen beschrieben.

CWWKS9105E: Der SSL-Port für automatische Umleitung konnte nicht bestimmt werden.
Dieser Fehler tritt auf, wenn Sie versuchen, auf eine Anwendung zuzugreifen, die an einen SSL-Port umgeleitet wird, und der SSL-Port nicht verfügbar ist. Der Port ist möglicherweise wegen einer fehlenden SSL-Konfiguration oder wegen eines Fehlers in der Definition der SSL-Konfiguration nicht verfügbar. Überprüfen Sie die SSL-Konfiguration in der Datei server.xml, um sicherzustellen, dass sie vorhanden und korrekt ist. Weitere Informationen hierzu finden Sie unter Kommunikation mit Liberty schützen.
FFDC1015I: An FFDC Incident has been created: "java.lang.IllegalArgumentException: Unknown, incomplete configuration: missing id field com.ibm.ws.config.internal.cm.ManagedServiceFactoryTracker aSyncReadNupdate. Exception thrown while trying to read configuration and update ManagedServiceFactory. Exception = java.lang.IllegalArgumentException: Unknown, incomplete configuration: missing id field" at ffdc_12.04.18_16.09.42.0.log
Dieser Fehler tritt auf, wenn ein Element keystore ohne ein Feld "ID" in der Konfiguration enthalten ist. Wenn Sie eine SSL-Minimalkonfiguration verwenden, setzen Sie das Feld "ID" auf defaultKeyStore.
Es tritt möglicherweise eine Ausnahme auf, wenn Sie eine LDAP-Benutzerregistry verwenden, bei der "sslEnabled" auf "true" gesetzt ist, jedoch kein Wert für "sslRef" angegeben wurde.
In der folgenden Beispielkonfiguration ist der Wert von sslEnabled "true", aber es ist kein Wert für sslRef angegeben:
<ltldapRegistry id="ldap" realm="SampleLdapIDSRealm" 
host="ccwin12.austin.ibm.com" port="636" ignoreCase="true"
baseDN="o=ibm,c=us"
bindDN="cn=root"
bindPassword="rootpwd"
ldapType="IBM Tivoli Directory Server"
idsFilters="ibm_dir_server"
sslEnabled="true"
searchTimeout="8m" />
Sie müssen einen Wert für sslRef angeben. Wenn Sie eine SSL-Minimalkonfiguration wie
<ltkeyStore id="defaultKeyStore" location="key.jks"
password="mypassword" />
verwenden, muss sslRef auf defaultSSLConfig gesetzt werden.

Bei einer angepassten SSL-Konfiguration muss der Name dieser Konfiguration in sslRef angegeben werden.

Wenn Sie ein JDK von WebSphere Application Server verwenden, wird möglicherweise der folgende Fehler angezeigt, wenn SSL in Ihrem Liberty-Server aktiviert ist.
java.net.SocketException: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory 
      at javax.net.ssl.DefaultSSLSocketFactory.a(SSLSocketFactory.java:11) 
      at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:6) 
      at com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:161) 
      at com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:36) 
      at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1184) 
      at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:390) 
      at com.ibm.net.ssl.www2.protocol.https.b.getResponseCode(b.java:75) 
      at com.ibm.ws.jmx.connector.client.rest.internal.RESTMBeanServerConnection.loadJMXServerInfo(RESTMBeanServerConnection.java:142) 
      at com.ibm.ws.jmx.connector.client.rest.internal.RESTMBeanServerConnection.<init>(RESTMBeanServerConnection.java:114) 
      at com.ibm.ws.jmx.connector.client.rest.internal.Connector.connect(Connector.java:315) 
      at com.ibm.ws.jmx.connector.client.rest.internal.Connector.connect(Connector.java:103) 
Dieser Fehler tritt auf, weil die SSL-Socket-Factorys von WebSphere Application Server nicht von Liberty unterstützt werden. Sie können dieses Problem mit den folgenden Schritten beheben:
  • Erstellen Sie eine Textdatei, z. B. my.java.security, mit den folgenden beiden leeren Einträgen:
    ssl.SocketFactory.provider=
    ssl.ServerSocketFactory.provider=
  • Erstellen Sie eine Datei jvm.options für Ihren Liberty-Server.
  • Fügen Sie Ihrer Datei jvm.options die folgende Eigenschaft hinzu, die den vollständigen Pfad zu Ihrer soeben erstellten Textdatei enthält.
    -Djava.security.properties=vollständiger_Pfad_zu/my.java.security 
  • Wenn Sie den Code wiederverwendbar machen möchten, können Sie die Datei my.java.security in Ihrem Serververzeichnis speichern und anschließend einen relativen Pfad verwenden. Beispiel:
    -Djava.security.properties=./my.java.security 

Weitere Informationen finden Sie im Artikel Liberty-Umgebung anpassen.

Fehlerbehebung für CORBA/IIOP

In diesem Abschnitt sind verschiedene häufige CORBA-Probleme und entsprechende Lösungen beschrieben.

Wird ein JDK von WebSphere Application Server verwendet, wird möglicherweise der folgende Fehler angezeigt, wenn Ihre Anwendung die CORBA/IIOP-Kommunikation verwendet.
15:21:58.096 com.ibm.rmi.pi.InterceptorManager runPreInit:178 Init Process ORBRas [default]  java.lang.ClassNotFoundException:
com.ibm.ISecurityLocalObjectBaseL13Impl.CSIClientRI
        at com.ibm.CORBA.iiop.UtilDelegateImpl.loadClass(UtilDelegateImpl.java:685)
        at javax.rmi.CORBA.Util.loadClass(Util.java:246)
        at com.ibm.rmi.pi.InterceptorManager.runPreInit(InterceptorManager.java:172)
        at com.ibm.rmi.corba.ORB.initializeInterceptors(ORB.java:664)
        at com.ibm.CORBA.iiop.ORB.initializeInterceptors(ORB.java:1084)
        at com.ibm.rmi.corba.ORB.orbParameters(ORB.java:1359)
        at com.ibm.rmi.corba.ORB.set_parameters(ORB.java:1271)
        at com.ibm.CORBA.iiop.ORB.set_parameters(ORB.java:1694)
        at org.omg.CORBA.ORB.init(ORB.java:371) 
        ...

Dieser Fehler tritt auf, weil die WebSphere Application Server-ORB-Interceptors nicht von Liberty unterstützt werden. Sie können dieses Problem beheben, indem Sie die Datei orb.properties aus dem JDK so bearbeiten, dass diese Interceptors nicht verwendet werden. Diese Datei befindet sich im WebSphere-Verzeichnis <JAVA_HOME>/jre/lib, obwohl sie durch eine Kopie aus dem <USER_HOME>-Verzeichnis des Benutzers überschrieben werden kann. Das folgende Beispiel zeigt die Zeilen in der Datei orb.properties, die auf Kommentar gesetzt werden müssen:

# WS-Interceptors
#org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.Transaction.JTS.TxInterceptorInitializer
#org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ejs.ras.RasContextSupport
#org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ISecurityLocalObjectBaseL13Impl.ClientRIWrapper
#org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.activity.remote.cos.ActivityServiceClientInterceptor
#org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ISecurityLocalObjectBaseL13Impl.CSIClientRI 
#org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.debug.olt.ivbtrjrt.OLT_RI
#org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.wlm.client.WLMClientInitializer

# WS-ORB- & Plug-in-Eigenschaften
#com.ibm.ws.orb.transport.ConnectionInterceptorName=com.ibm.ISecurityLocalObjectBaseL13Impl.SecurityConnectionInterceptor

Fehlerbehebung für die Protokollierung und Traceerstellung

In diesem Abschnitt sind einige häufige Probleme mit der Protokollierung und Traceerstellung beschrieben.

java.util.logging -- Programmierschnittstelle für Java-Protokollierung
Liberty unterstützt nicht die Verwendung der Datei logging.properties für die Konfiguration von java.util.logging. Verwenden Sie Java-Code, zum Beispiel in einer implementierten Anwendung oder in einem Benutzerfeature, um java.util.logging-Handler, -Filter oder -Formatierer zu erstellen und hinzuzufügen.
Da der Liberty-Server die java.util.logging-Protokollstufen gemäß der Festlegung im Attribut traceSpecification des Protokollkonfigurationselements verwaltet, sollten Sie die Methode Logger.setLevel nicht verwenden.

Fehlerbehebung für JAX-WS

In diesem Abschnitt werden einige allgemeine JAX-WS-Probleme und auswählbare Lösungen beschrieben.

Die Ausnahme org.apache.cxf.bus.extension.ExtensionException ist aufgetreten, als Sie Web-Service-Anwendungen in Liberty implementiert haben.
Wenn Ihre Anwendung CXF-Bibliotheken und -Konfigurationen enthält, die bereits integriert sind, und Sie möchten die Anwendung in Liberty implementieren, müssen Sie sicherstellen, dass das Server-Feature jaxws-2.2 inaktivert ist, indem Sie das Feature aus der Datei server.xml entfernen.
Die Ausnahme "java.lang.NoClassDefFoundError" ist aufgetreten, als Sie den IBM® Direktaufruf für die Oracle-JVM ausgeführt haben.
Wenn Sie den IBM JAXB-Direktaufruf (Java Architecture for XML Binding) verwenden möchten, können Sie mit der angepassten Eigenschaft com.ibm.xml.xlxp.jaxb.opti.level steuern, ob Optimierungsmethoden für JAXB-Unmarshalling (Deserialisierung) und -Marshalling (Serialisierung) aktiviert werden. Wenn Sie die Ausnahme java.lang.NoClassDefFoundError auftritt, wenn Sie den IBM Direktaufruf JAXB für die Oracle-JVM ausführen, können Sie den Wert der Eigenschaft com.ibm.xml.xlxp.jaxb.opti.level auf 0 setzen, um die Optimierung zu inaktivieren. Sie können die Eigenschaft -Dcom.ibm.xml.xlxp.jaxb.opti.level=0 beispielsweise in der Befehlszeile verwenden oder der Datei jvm.options die folgende Zeile hinzufügen:
# JAXB-Optimierung inaktivieren
-Dcom.ibm.xml.xlxp.jaxb.opti.level=0
Weitere Informationen zur Eigenschaft com.ibm.xml.xlxp.jaxb.opti.level finden Sie auf der Seite Angepasste JVM-Eigenschafen (Java Virtual Machine).
Die Ausnahme "java.lang.NoClassDefFoundError : com.ibm.CORBA.iiop.ORB" ist aufgetreten, als Sie den WebSphere Application Server Traditional-Thin-Client mit der Oracle-JVM ausgeführt haben.
Dieser Fehler tritt auf, wenn Sie versuchen, den WebSphere Application Server Traditional-Thin-Client mit der Oracle-JVM auszuführen, während das Feature jaxws-2.2 bereits in Liberty aktiviert ist. Sie beheben dieses Problem, indem Sie die Eigenschaft -Dcom.ibm.websphere.thinclient=true wie folgt verwenden, wenn Sie den WebSphere Application Server Traditional-Thin-Client ausführen:
java -Dcom.ibm.websphere.thinclient=true 
     -cp <Klassenpfadeinträge_mit_Classic-Thin-Client-JAR> <Web-Service-Client-Eintragsklasse> <weitere_Parameter>
Sehen Sie sich ähnliche Informationen zur Eigenschaft com.ibm.websphere.thinclient auf der Seite PM39777: ADMINISTRATIVE THIN CLIENT USING SOAP CONNECTOR AND SUN JDK DOES NOT WORK an.
Eine leere Datei, die zurückgegeben wird, wenn Sie Binärdateien aus einem MTOM-Service für einen MTOM-Client abrufen.
Dieses Szenario entsteht, wenn ein MTOM-Client Binärdateien erfolgreich an einen MTOM-Service gesendet hat, jedoch eine leere Datei zurückgegeben wird, wenn Sie dieselben Bindärdateien vom MTOM-Service zurückbekommen.
Als Ausweichlösung können Sie einen neuen DataHandler erstellen und den DataHandler initialisieren, indem Sie den Inhalt der Binärdatei eintragen. Verwenden Sie beispielsweise ein FileDataStore-Objekt, um Daten aus der Ein-/Ausgabe zu lesen und den neu erstellten DataHandler zurückzugeben und den DataHandler dann an andere Web-Services zu übergeben.
...
File f = new File("received_image");
		if (f.exists()) {
				f.delete();
	}

		FileOutputStream fos = new FileOutputStream(f);
		img_in.writeTo(fos);

		FileDataSource fos_out = new FileDataSource(f);
		DataHandler img_out = new DataHandler(fos_out);
		return img_out;
...
Der Fehler "javax.xml.ws.soap.SOAPFaultException: Unmarshalling Error" ist aufgetreten, als Sie die Klasse "XMLGregorianCalendar" im Format xsd:gMonth mit der Oracle-JVM verwendet haben.
Dieser Fehler tritt auf, wenn Sie die Klasse XMLGregorianCalendar zum Speichern von Konstanten im Format gMonth im Rahmen Ihrer SOAP-Anforderung auf Clientseite verwenden und das Feature jaxws-2.2 für die Oracle-JVM in Liberty aktiviert ist. Die eigentliche (Fehler-)Ursache besteht darin, dass die Oracle-JVM das neue Standardformat --MM für den Typ xsd:gMonth unterstützt, während die aktuellste JAXB-RI (Referenzimplementierung) nur das Format --MM-- unterstüzt.
Sie können dieses Problem beheben, indem Sie die Oracle-JVM für die clientseitigen und die serverseitigen Anwendungen durch die IBM JVM ersetzen.
Beim Auflösen der mit dem Attribut "wsdlLocation" angegebenen WSDL-Dateien tritt eine Ausnahme des Typs "java.io.FileNotFoundException" ein
Dieser Fehler tritt auf, wenn Sie die WSDL-Datei wie im Code wsdlLocation = "file:/WEB-INF/wsdl/a.wsdl" angeben und die WSDL-Datei im Paket Ihrer Anwendung enthalten ist. Wenn Sie auf die WSDL-Datei verweisen möchten, die im Paket Ihrer Anwendung enthalten ist, müssen Sie die relativen URIs für das Attribut wsdlLocation verwenden, das in der Annotation @WebService, @WebServiceProvider, @WebServiceClient oder @WebServieRef definiert ist.
Der relative URI für das Attribut wsdlLocation muss einen der folgenden Werte haben:
  • wsdlLocation = "/WEB-INF/wsdl/a.wsdl"
  • wsdlLocation = "WEB-INF/wsdl/a.wsdl"
In der Datei "messages.log" werden sehr viele Nachrichten des Typs "Creating Server" erfasst.
Dieses Szenario tritt ein, wenn Sie die Methode getPort oder zugehörige Methoden in den generierten Client-Stub-Klassen aufrufen. Liberty ist mit der Standardprotokollierungskonfiguration konfiguriert und alle Informationsnachrichten werden in die Datei messages.log geschrieben. Es werden zahlreiche Vorkommen von Nachrichten aufgezeichnet, die der folgenden gleichen:
00000037 org.apache.cxf.service.factory.ReflectionServiceFactoryBean I Creating Service {http://www.echo.org/}EchoService from WSDL: 
    wsjar:file:/wlp/usr/servers/default/workarea/org.eclipse.osgi/bundles/100/data/cache/
    com.ibm.ws.app.manager_gen_15a42559-f979-4ee6-b488-9fa1fb212c96/.cache/Echo.war!/WEB-INF/wsdl/Echo.wsdl
Wenn Sie diese Informationsnachrichten unterdrücken möchten, können Sie die Protokollierungskonfiguration in der Datei server.xml wie folgt ändern:
<logging traceSpecification="org.apache.cxf.*=warning=enabled"/>
Wenn eine Clientanwendung eine SOAP-Aktion sendet, tritt eine Ausnahme des Typs "SOAPFaultException" (der angegebene SOAPAction-Test stimmt mit keiner Operation überein) ein
Anmerkung: test ist der Wert des Attributs soapAction im HTTP-Header der Anforderung.
Jede Operation in einem SOAP-Web-Service kann einer SOAP-Aktionszeichenfolge zugeordnet werden, z. B. in der WSDL-Bindung oder in einer Annotation. Der Web-Service-Client sendet die SOAP-Aktionszeichenfolge als Header mit der Anforderung, um sie mit der Operation des Web-Service-Providers abzugleichen. Die Fehlernachricht wird in den folgenden Szenarien angezeigt:
  • Wenn die vom Client gesendete SOAP-Aktion nicht mit der SOAP-Aktion der Operation übereinstimmt.
  • Wenn WebSphere Application Server Traditional als JAX-WS-Client und Liberty als JAX-WS-Service verwendet wird und der in der WSDL-Datei definierte Wert für soapAction dem leeren Wert "" entspricht.
Gehen Sie wie folgt vor, um dieses Problem zu lösen:
  • Stellen Sie sicher, dass für den Web-Service-Client und den Service-Provider genau dieselbe SOAP-Aktion angegeben wird.
  • Geben Sie einen gültigen Wert für das in der WSDL-Datei definierte Attribut soapAction an oder verwenden Sie soapAction nicht in der WSDL-Datei.
Bei der Verwendung der Methode "Service.create()" zum Erstellen eines Service tritt die Ausnahme "javax.xml.ws.WebServiceException" ein.
Dieser Fehler tritt auf, wenn Sie die Methode Service.create() verwenden, um einen Service zu erstellen, aber das WSDL-Dokument nicht bereitgestellt wird. Wenn Sie die Methode Service.create() zum Erstellen eines Service und die Methode getPort() zum Abrufen der Portnummer verwenden möchten, müssen Sie die Methode addPort() verwenden, um die Bindungsinformationen anzugeben.
Im Folgenden sehen Sie ein Codebeispiel für die Verwendung der Methode addPort():
QName serviceName = new QName("http://test.com/wssvt/acme/InsBusiness/", "MTOM11Service");
QName portName = new QName("http://test.com/wssvt/acme/InsBusiness/", "MTOM11Port");

// Erforderliche JAX-WS-Artefakte konfigurieren
Service svc = Service.create(serviceName);
// Port in der Serviceinstanz hinzufügen
svc.addPort(portName, SOAPBinding.SOAP11HTTP_MTOM_BINDING, mtom11URL); 

port = svc.getPort(portName, MTOMInterface.class);
Es wird eine Nullantwort zurückgegeben, wenn das Attribut "name" in der Annotation "@WebResult" vom Element "name" im WSDL-Dokument abweicht
Dieses Problem tritt auf, wenn Sie eine SEI-Klasse verwenden, um das Attribut name für die Annotation @WebResult zu definieren, und die WSDL-Position in der SEI-Klasse folgendermaßen angegeben ist:
@WebService(wsdlLocation="WEB-INF/wsdl/WebServiceIfc.wsdl")
public interface WebServiceRuntimeIfc {
        @WebMethod
        @WebResult(name="nononoreturn") 
        public String echo (String parm);
}
aber die XML-Elementdeklaration im bereitgestellten WSDL-Dokument wie folgt lautet:
<xs:element name="echoResponse">
		<xs:complexType>
				<xs:sequence>
						<xs:element name="return" type="xs:string" minOccurs="0"/>
				</xs:sequence>
		</xs:complexType>
</xs:element>
In diesem Fall empfängt der Web-Service-Client eine Nullantwort, wenn die Methode echo() aufgerufen wird.
Zur Behebung dieses Problems stellen Sie sicher, dass das Attribut name der Annotation @WebResult mit dem Wert des Elements name im WSDL-Dokument übereinstimmt.
Die JAX-WS-Clientanwendung kann die Änderungen im WSDL-Dokument nicht von der Serverseite abrufen
Das Problem tritt auf, wenn sich der Web-Service-Client und der Service-Provider in zwei verschiedenen Anwendungen in Liberty befinden und der Client das WSDL-Dokument dynamisch vom Service-Provider abrufen muss. Liberty speichert die WSDL-Definition im Cache, wenn das WSDL-Dokument zum ersten Mal aufgerufen wird. Dies weicht vom Verhalten in WebSphere Application Server Traditional ab. Durch das Caching der WSDL-Definition in Liberty können Anwendungen häufige Verbindungsherstellungen und Syntaxanalysen des WSDL-Dokuments vermeiden.
Sie können dieses Problem beheben, indem Sie die Clientanwendung erneut starten, sodass die aktualisierten WSDL-Definitionen neu geladen werden können.
JAXB-Warnung während des WSDL-Imports
Beim Import einer WSDL-Datei kann die folgende Warnung angezeigt werden:
[WARNING] unknown extensibility element or attribute "wsdl" (in namespace "http://www.w3.org/2000/xmlns/" (http://www.w3.org/2000/xmlns/%27) )

Fehlerbehebung für WS-Security

In diesem Abschnitt sind einige allgemeine Lösungen beschrieben, die Sie zur Behebung von WS-Security-Problemen verwenden können.
  1. Überprüfen Sie die Datei server.xml, um sicherzustellen, dass die erforderlichen JAX-WS- (jaxws-2.2) und Sicherheitsfeatures (appSecurity-2.0) ordnungsgemäß konfiguriert sind.
  2. Wenn Sie Ihre Web-Service-Anwendung mit WS-Security schützen möchten, muss Ihre JAX-WS-Anwendung eine WSDL-Datei enthalten, die eine integrierte WS-Security-Richtlinie enthält. Es muss eine PolicyReference auf die integrierte WS-Security-Richtlinie im Abschnitt wsdl:binding und/oder im Abschnitt wsdl:operation vorhanden sein.
  3. Wenn Sie einen Callback-Handler für den Abruf von Kennwörtern zum Generieren von Benutzernamenstokens oder für den Abruf von Kennwörtern für private Schlüssel aus Keystore-Dateien verwenden, muss der Callback-Handler für Kennwörter als Benutzerfeature in Liberty gepackt und implementiert werden.

WS-Security-Trace aktivieren

Falls die Ursache des Problems anhand der Informationen in der Fehlernachricht nicht bestimmt werden kann, können Sie die Liberty-Trace- und Protokollfunktion verwenden, um den Trace für die WS-Security-Komponente zu erfassen. Weitere Informationen finden Sie unter Liberty: Traceerstellung und Protokollierung.

Sie können die folgende Tracezeichenfolge verwenden, um den Trace für das Debugging von WS-Security-Fehlern zu erfassen:
org.apache.ws.security.*=all=enabled:
org.apache.cxf.ws.security.*=all=enabled:
org.apache.cxf.ws.policy.*=all=enabled
org.apache.xml.security.*=all=enabled:
com.ibm.ws.wssecurity.*=all=enabled

In diesem Abschnitt sind verschiedene häufige WS-Security-Probleme und deren Lösungen beschrieben:

org.apache.cxf.ws.policy.PolicyException: Keine der Richtlinienalternativen kann erfüllt werden.
Dieser Fehler tritt gewöhnlich auf, wenn das WS-Security-Feature wsSecurity-1.1 nicht in der Datei server.xml definiert ist. Sie können diesen Fehler vermeiden, indem Sie das Feature wsSecurity-1.1 in der Datei server.xml wie folgt definieren:
<featureManager>   <feature>usr:wsseccbh-1.0</feature>
  <feature>servlet-3.0</feature>
  <feature>appSecurity-2.0</feature>
  <feature>jaxws-2.2</feature>
  <feature>wsSecurity-1.1</feature>
</featureManager>
org.apache.cxf.ws.policy.PolicyException: Es ist kein Callback-Handler und kein Kennwort verfügbar.
Dieser Fehler tritt auf, wenn die WS-Security-Laufzeitumgebung ein Kennwort, das für die Generierung eines Benutzernamenstokens oder für den Zugriff auf einen privaten Schlüssel im Keystore erforderlich ist, nicht abrufen kann. Überprüfen Sie die folgende Konfiguration, um diesen Fehler zu vermeiden:
  1. Stellen Sie sicher, dass das Callback-Handler-Feature für Kennwörter, wsseccbh-1.0, als Benutzerfeature in der Datei server.xml definiert ist:
    <featureManager>   <feature>usr:wsseccbh-1.0</feature>
      <feature>servlet-3.0</feature>
      <feature>appSecurity-2.0</feature>
      <feature>jaxws-2.2</feature>
      <feature>wsSecurity-1.1</feature>
    </featureManager>
  2. Stellen Sie sicher, dass die Callback-Handler-Eigenschaft ws-security.callback-handler im Element <wsSecurityClient> oder <wsSecurityProvider> der Datei server.xml definiert ist:
    ws-security.callback-handler="<vollständiger Klassenname des Callback-Handlers>"
    
    Beispiel:
    ws-security.callback-handler="com.ibm.ws.wssecurity.example.cbh.CommonPasswordCallback"
  3. Stellen Sie sicher, dass der Callback-Handler für Kennwörter das richtige Kennwort für den Benutzernamen bzw. Schlüsselalias zurückgibt, der in der Datei server.xml angegeben ist. Das Kennwort muss in Klartext zurückgegeben werden und darf weder codiert noch verschlüsselt sein.
org.apache.ws.security.WSSecurityException: Die Signatur deckt die erforderlichen Elemente (soap:Body) nicht ab
Dieser Fehler tritt auf, wenn eine Web-Service-Provider-Anwendung erwartet, dass der SOAP-Hauptteil in der Anforderungsnachricht signiert ist, der SOAP-Hauptteil in der empfangenen SOAP-Nachricht aber nicht signiert ist. Sie können diesen Fehler vermeiden, indem Sie sicherstellen, dass Ihr Web-Service-Client mit der richtigen WS-Security-Richtlinie konfiguriert ist, die mit der Richtlinie des Web-Service-Providers übereinstimmt.
org.apache.ws.security.WSSecurityException: Die Signatur oder Entschlüsselung ist ungültig
Dieser Fehler tritt auf, wenn die WS-Security-Laufzeitumgebung die Signatur nicht validieren oder einen verschlüsselten Nachrichtenteil in der empfangenen SOAP-Nachricht nicht entschlüsseln kann. Sie können diesen Fehler vermeiden, indem Sie sicherstellen, dass die richtigen Schlüssel bei der Konfiguration von WS-Security in den Elementen <wsSecurityClient> und <wsSecurityProvider> der Datei server.xml verwendet werden. Wenn ein Web-Service-Client beispielsweise den öffentlichen Schlüssel von Bob zum Verschlüsseln eines Nachrichtenteils verwendet, muss der Web-Service-Provider Zugriff auf den privaten Schlüssel von Bob haben, um die Nachricht zu entschlüsseln. Wenn ein Web-Service-Client beispielsweise einen Nachrichtenteil mit dem privaten Schlüssel von Alice signiert, muss der Web-Service-Provider den öffentlichen Schlüssel von Alice verwenden, um die Signatur zu validieren.
org.apache.cxf.ws.policy.PolicyException: Diese Richtlinienalternativen können nicht erfüllt werden.
Dieser Fehler tritt auf, wenn die WS-Security-Laufzeitumgebung die eingehende SOAP-Nachricht anhand der WS-Security-Richtlinie, die für die Verarbeitung dieser Anforderung konfiguriert ist, nicht verarbeiten kann. Um diesen Fehler zu vermeiden, sehen Sie sich die Nachrichten an, die dieser Ausnahme folgen, um die spezifischen WS-Security-Richtlinienzusicherungen zu bestimmen, die diese Ausnahme verursachen. Die Protokolldatei könnte beispielsweise die folgenden Nachrichten enthalten:
Caused by: org.apache.cxf.ws.policy.PolicyException: These policy alternatives can not be satisfied: 
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}AsymmetricBinding: The encryption algorithm does not match the requirement
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}InitiatorEncryptionToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RecipientEncryptionToken
at org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:167)
at org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(PolicyVerificationInInterceptor.java:101)
In diesem Fall tritt der Fehler auf, weil der Verschlüsselungsalgorithmus, der vom Web-Service-Client verwendet wird, nicht mit dem Verschlüsselungsalgorithmus übereinstimmt, der in der AlgorithmSuite-Zusicherung angegeben ist. Die in der WS-Security-Richtlinie des Web-Service-Clients und des Web-Service-Providers angegebenen Algorithmussuites müssen denselben Verschlüsselungsalgorithmus angeben.
javax.xml.ws.soap.SOAPFaultException: The message has expired (WSSecurityEngine: Invalid timestamp The security semantics of the message have expired).
Diese Nachricht wird ausgegeben, wenn die Nachrichtenzeitmarke abgelaufen ist oder wenn die Nachricht mit einer Zeitmarke erstellt wurde, die in der Zukunft liegt.
Für verteilte PlattformenFür IBM i-Plattformen

Fixpacks und vorläufige Fixes auf eine Archivinstallation anwenden

Wenn Sie Ihre Liberty-Laufzeitumgebung über eine Archivdatei und nicht mithilfe von Installation Manager installiert haben, müssen Sie spezielle Maßnahmen bei der Anwendung von Serviceaktualisierungen ergreifen. Weitere Informationen finden Sie unter Fixpack auf eine Java-Archivinstallation von Liberty anwenden und Vorläufigen Fix auf Liberty-Archivinstallation anwenden.

Fehlerbehebung für die Leistung

In diesem Abschnitt sind einige häufige Leistungsprobleme und auswählbare Lösungen beschrieben.

Hohe CPU-Belastung durch den Anwendungsmonitor

Dieser Fehler kann auftreten, wenn im Verzeichnis apps/ Ihres Anwendungsmonitor viele Dateien enthalten sind und der Monitor häufig Abfragen durchführt.

Sie können einige Punkte ändern, um dieses Problem zu beheben.

  1. Erhöhen Sie den Wert des Attributs pollingRate im Element applicationMonitor.
  2. Aktualisieren Sie die Datei server.xml so, dass ein Element applicationMonitor mit updateTrigger ohne den Status polled enthalten ist.
    server.xml
    <applicationMonitor updateTrigger="mbean" /> 
  3. Verringern Sie die Anzahl der Dateien im Verzeichnis apps/.

Weitere Informationen zum Element applicationMonitor finden Sie unter Dynamische Aktualisierungen steuern.

Fehlerbehebung für Verbünde

In diesem Abschnitt werden ein Problem mit Verbünden und die entsprechende Lösung beschrieben.

java.lang.IllegalArgumentException: CWWKX0219E: Die MBean 'WebSphere:feature=collectiveController,type=CollectiveRepository,name=CollectiveRepository' hat keine Operation mit dem Namen 'retrieveMemberRootCertificate'.
Ein Server mit dem Feature collectiveMember-1.0 (Member) kann sich nicht bei einem Server mit dem Feature collectiveController-1.0 (Controller), der eine ältere Version von Liberty hat, registrieren. Ein Member mit dieser Betaversion von Liberty kann sich beispielsweise nicht bei einem Controller mit der Version 8.5.5.2 von Liberty registrieren.

Bei der Standardprotokollierung wird dieses Problem als First-Failure Data Capture (FFDC) in den FFDC-Protokollen des Members berichtet.

Zur Behebung des Problems müssen Sie den Controller auf die Liberty-Version des Members oder eine höhere Version aktualisieren.

Fehlerbehebung für SAML

In diesem Abschnitt werden ein Problem mit SAML und die entsprechende Lösung beschrieben.

java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 0
Diese Ausnahme kann eintreten, wenn über eine nicht vom Service-Provider (SP) angeforderte Anforderung mehrere Anmeldeversuche getätigt werden, ohne das IdP-Token (Identitätsprovider) zu entfernen.
Um diese Ausnahme zu verhindern, fügen Sie den Eintrag <httpSession invalidateOnUnauthorizedSessionRequestException="true" /> in der entsprechenden nicht angeforderten Datei server.xml hinzu.
java.lang.IllegalStateException: CWWKS0010E: Beim Abrufen des Caller-Principals wurde festgestellt, dass ein Caller-Subjekt mehrere Principals des Typs WSPrincipal hat. Es ist nur ein einziger WSPrincipal pro Subjekt zulässig. Die Namen der WSPrincipals sind {0}
Diese Ausnahme kann eintreten, wenn sich ein SAML-Benutzer zuvor direkt an einer lokalen Benutzerregistry angemeldet hat. Um dieses Problem zu vermeiden, darf sich ein SAML-Benutzer nicht direkt an einer lokalen Benutzerregistry anmelden.

Fehlerbehebung für die REST-API-Erkennung

Wenn die IBM REST API Discovery Explorer-Auswahl "Try it out" über Fernzugriff aufgerufen wurde und mit einem Antwortcode von 0 fehlschlägt, stellen Sie sicher, dass der vollständig qualifizierte Hostname oder die IP-adresse an den IBM REST API Discovery Explorer im Curl- und Anforderungs-URL zurückgegeben wird, der zur Operation GET, PUT, POST oder DELETE gehört. Wenn sich der vollständig qualifzierte Hostname oder die IP-Adresse nicht im Curl- und Anforderungs-URL befindet, führen Sie die folgenden Aktionen aus:

  1. Fügen Sie das Variablenelement der Datei server.xml hinzu und geben Sie den vollständig qualifizierten Hostnamen an. Im Folgenden sehen Sie ein Beispiel für das Hinzufügen des Variablenelements, das den vollständig qualifizierten Hostnamen in der Datei server.xml angibt.
     <httpEndpoint host="*" httpPort="9080" httpsPort="9443" id="defaultHttpEndpoint"/>          
    <variable name="defaultHostName" value="developer.rtp.raleigh.ibm.com"/>
  2. Für verteilte Plattformen Geben Sie den vollständigen Computernamen für Ihr Betriebssystem als vollständig qualifizierten Hostname an.
  3. Vergewissern Sie sich, dass der vollständig qualifizierte Hostname im Curl- und Anforderungs-URL zurückgegeben wird, der zu den GET-, PUT-, POST- oder DELETE-Operationen gehört. Weitere Informationen finden Sie unter Standardhostnamen für einen Liberty-Server festlegen sowie in der Produktdokumentation von IBM InfoSphere Information Server Version 11.3.1 im Abschnitt zur Netzkonfiguration.

Symbol das den Typ des Artikels anzeigt. Referenzartikel

Dateiname: rwlp_trouble.html