Liberty:Tipps zur Fehlerbehebung
Tipps zur Fehlerbehebung in Liberty.
Zur Unterstützung beim Ermitteln und Beheben von Fehlern stellt das Produkt eine einheitliche Protokollierungskomponente bereit. Nähere Informationen hierzu finden Sie unter Protokollierung und Traceerstellung. Sie können auch das Befehlstool IBM® Support Assistant Data Collector (ISADC) im Verzeichnis ${wlp.install.dir}/bin verwenden, um Diagnosedateien wie Protokolldateien und Konfigurationsdateien schnell zu erfassen und Traces auszuführen.
Wenn Sie eine Ausnahmenachricht empfangen, finden Sie unter Liberty:Nachrichten Informationen zu dieser Nachricht.
Die Java™-API-Dokumentation für jede Liberty-API finden Sie in einer separaten .zip-Datei in einem der Javadoc-Unterverzeichnisse des Verzeichnisses ${wlp.install.dir}/dev.

Einzelheiten zu den bekannten Einschränkungen, die
bei der Verwendung von Liberty gelten, finden Sie unter Liberty: Bekannte Probleme und Einschränkungen für die Laufzeitumgebung.
- Fehlerbehebung für JDKs
- Fehlerbehebung für die Sicherheit
- Fehlerbehebung für LDAP
- Fehlerbehebung für SSL
- Fehlerbehebung für CORBA/IIOP
- Fehlerbehebung für die Protokollierung und Traceerstellung
- Fehlerbehebung für JAX-WS
- Fehlerbehebung für WS-Security
Fixpacks und vorläufige Fixes auf eine Archivinstallation anwenden
- Fehlerbehebung für die Leistung
- Fehlerbehebung für Verbünde
- Fehlerbehebung für SAML
- Fehlerbehebung für die REST-API-Erkennung
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. Nähere 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 Sitzungssicherheit.
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 den Fehler zu beheben. Wenn Sie die Anwendung im Ordner dropins belassen,
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. Nähere Informationen hierzu finden Sie unter Liberty: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 keine Sicherheitsfunktion (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 Liberty:Öffentliche Sicherheits-APIs.
- 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
- Um Benutzer authentifizieren zu können, deren Namen Unicode-Zeichen enthalten, müssen Sie den vom Liberty-Server verwendeten Zeichencodierungstyp UTF-8 festlegen, 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. Überprüfen Sie Ihren LDAP-Server, um sicherzustellen, dass er aktiv ist und dass seine IP-Adresse über den Liberty-Server erreichbar 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 in Ihrem LDAP-Server aktivieren, ohne den Unterzeichner des LDAP-Servers in den Truststore zu kopieren, der im Element LDAPSSLSettings referenziert wird, schlägt eine Verbindung zum LDAP-Server mit einem SSL-Handshakefehler 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 kann in den FFDC-Protokollen angezeigt werden und zeigt an, dass die verwendbaren Sockets auf dem lokalen Server aufgebraucht sind, was zu einem Fehler beim Herstellen der Verbindung zum LDAP-Server führt. 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 kann im Server auftreten, obwohl der in der Nachricht erwähnte Benutzer auf dem LDAP-Server mit hoher Belastung ein gültiger Benutzer 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.
- Wenn Sie eine LDAP-Benutzerregistry mit sslEnabled verwenden und keinen sslRef-Wert angeben, kann eine Ausnahme ausgelöst werden.
- 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
verwenden, muss sslRef auf defaultSSLConfig gesetzt werden.<ltkeyStore id="defaultKeyStore" location="key.jks" password="mypassword" />
Bei einer angepassten SSL-Konfiguration muss der Name dieser Konfiguration in sslRef angegeben werden.
- Wird ein JDK von WebSphere Application Server verwendet, wird möglicherweise der folgende Fehler angezeigt, wenn SSL für Ihren 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
- Um die Wiederverwendbarkeit der Datei zu verbessern, können Sie die Datei
my.java.security in Ihrem Serververzeichnis speichern. Daraufhin können Sie einen relativen Pfad wie den folgenden
verwenden:
-Djava.security.properties=./my.java.security
Weitere Informationen finden Sie unter Liberty-Umgebung anpassen.
- Erstellen Sie eine Textdatei, z. B. my.java.security, mit den folgenden beiden leeren Einträgen:
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 ORB-Interceptors (Object Request Broker) von WebSphere Application Server 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 gewöhnlich im WebSphere-Verzeichnis <JAVA_HOME>/jre/lib, obwohl sie möglicherweise mit einer Kopie aus dem Verzeichnis <USER_HOME> des Benutzers überschrieben wurde. 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 die Verwendung der Datei logging.properties für die Konfiguration von java.util.logging nicht. Verwenden Sie Java-Code beispielsweise in einer implementierten Anwendung oder in einem implementierten Benutzerfeature, um Handler, Filter oder Formatierungsprogramme für java.util.logging zu erstellen und hinzuzufügen.
- Da der Liberty-Server die java.util.logging-Protokollierungsstufen in Übereinstimmung mit dem Attribut traceSpecification des Konfigurationselements für die Protokollierung verwaltet, müssen 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" tritt ein, wenn Web-Service-Anwendungen in Liberty implementiert werden
- Wenn Ihre Anwendung bereits integrierte CXF-Bibliotheken und -Konfigurationen enthält und Sie die Anwendung in Liberty implementieren möchten, müssen Sie sicherstellen, dass das Server-Feature jaxws-2.2 inaktiviert ist, indem Sie das Feature aus der Datei server.xml entfernen.
- Bei der Ausführung des IBM Direktaufrufs mit der Oracle-JVM tritt eine Ausnahme des Typs "java.lang.NoClassDefFoundError" ein
- 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.
Treten bei der Ausführung des IBM JAXB-Direktaufrufs mit der Oracle-JVM
Ausnahmen des Typs java.lang.NoClassDefFoundError ein, können Sie den Wert der Eigenschaft com.ibm.xml.xlxp.jaxb.opti.level
in 0 ändern, 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 Webseite Angepasste Eigenschaften der Java Virtual Machine.
- Bei der Ausführung des WebSphere Application Server Traditional-Thin-Clients mit der Oracle-JVM tritt die Ausnahme "java.lang.NoClassDefFoundError: com.ibm.CORBA.iiop.ORB" ein.
- Dieser Fehler tritt auf, wenn Sie versuchen, den WebSphere Application Server Traditional Thin Client mit der
Oracle-JVM auszuführen, und das Feature jaxws-2.2 bereits in Liberty aktiviert ist. Zur Behebung dieses
Problems können 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.
- Beim Abrufen von Binärdateien von einem MTOM-Service für einen MTOM-Client wird eine leere Datei zurückgegeben
- Dieses Szenario tritt ein, wenn ein MTOM-Client erfolgreich Binärdateien an einen MTOM-Service gesendet hat, aber eine leere Datei beim Abrufen derselben Binärdateien vom MTOM-Service zurückgegeben wird.
- 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; ...
- Bei der Verwendung von "XMLGregorianCalendar" im Format "xsd:gMonth" mit der Oracle-JVM tritt ein Fehler des Typs "javax.xml.ws.soap.SOAPFaultException: Unmarshalling" auf
- Dieser Fehler tritt auf, wenn Sie die Klasse XMLGregorianCalendar verwenden, um Konstanten im Format gMonth in Ihrer SOAP-Anforderung auf der Clientseite zu speichern, und das Feature jaxws-2.2 in Liberty mit der Oracle-JVM aktiviert ist. Die eigentliche Fehlerursache ist die, dass die Oracle-JVM das neue Standardformat --MM für den Typ xsd:gMonth verwendet, während die neueste JAXB-Referenzimplementierung (RI) nur das Format --MM-- unterstützt.
- 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" aufgezeichnet
- 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:
aber die XML-Elementdeklaration im bereitgestellten WSDL-Dokument wie folgt lautet:@WebService(wsdlLocation="WEB-INF/wsdl/WebServiceIfc.wsdl") public interface WebServiceRuntimeIfc { @WebMethod @WebResult(name="nononoreturn") public String echo (String parm); }
In diesem Fall empfängt der Web-Service-Client eine Nullantwort, wenn die Methode echo() aufgerufen wird.<xs:element name="echoResponse"> <xs:complexType> <xs:sequence> <xs:element name="return" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element>
- 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
- Ü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.
- 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.
- 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.
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:
- 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>
- 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"
- 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.
- Stellen Sie sicher, dass das Callback-Handler-Feature für Kennwörter, wsseccbh-1.0, als Benutzerfeature
in der Datei server.xml definiert ist:
- 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:
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.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)
- 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.


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.
- Erhöhen Sie den Wert des Attributs pollingRate im Element applicationMonitor.
- Aktualisieren Sie die Datei server.xml so, dass
ein Element applicationMonitor mit
updateTrigger ohne den Status
polled enthalten ist.
server.xml <applicationMonitor updateTrigger="mbean" />
- 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 Documentation 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 an den Curl- und Anforderungs-URL zurückgegeben wird, der zur GET-, PUT-, POST- oder DELETE-Operation 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:
- 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"/>
Geben Sie den vollständigen Computernamen für Ihr Betriebssystem als vollständig qualifizierten Hostname an.
- 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.