Liberty 的疑難排解提示

疑難排解資訊說明一般問題的解決方案。

為了協助您識別及解決問題,產品備有統一的記載元件。 請參閱 記載和追蹤

如果收到異常狀況訊息,Liberty:訊息提供訊息的相關資訊。

每一個 Liberty API 的 Java™ API 說明文件都是以個別的 .zip 檔來提供(其位於 ${wlp.install.dir}/dev 目錄下的其中一個 javadoc 子目錄中)。

如需使用 Liberty 時主要已知限制的詳細資料,請參閱執行時期環境的已知問題和限制

確認您的 JDK 是支援的層次

如果您遇到難以理解的問題,請確認您在使用的 JDK 符合 Java 第 7 版或更新的版本,且是最新的服務層次。 請參閱 最低的 Java 支援層次

安全疑難排解

這節說明一些常見的安全問題及您可以選擇的解決方案。

SESN0008E: 鑑別為匿名的使用者試圖存取 user:LdapRegistry/cn=steven,o=myCompany,c=US 所擁有的階段作業。
當未經鑑別的使用者試圖存取已鑑別的使用者所建立的階段作業,就會發生這個錯誤。 預設啟用的階段作業安全會防止未獲授權存取階段作業。 只有建立階段作業的使用者才可以存取該階段作業。 如需相關資訊,請參閱階段作業安全

當您的表單登入使用 JSP(如 login.jsp),但瀏覽器傳送的 SSO 記號過期時,可能會發生這個錯誤。 由於 SSO 記號過期,系統會提示使用者利用針對表單登入所配置的 login.jsp 頁面來重新登入。 依預設,這個 JSP 頁面會試圖取得階段作業。 這個階段作業最初是由記號已過期的使用者所建立。 由於記號過期且使用者未經鑑別,當您存取導致這個錯誤的這個階段作業時,不會建立任何認證。

如果要避免這個錯誤,請將啟動新階段作業的瀏覽器重新啟動,或將 login.jsp 檔配置成依預設不建立階段作業。 如果您選擇更新 login.jsp 檔,請設定 <%@ page session="false" %>

CWWKS9104A: 在 {2} 上呼叫 {1} 時,使用者 {0} 授權失敗。 使用者未獲授權存取任何必要的角色:{3}。
當您沒有應用程式所需要之角色的授權時,會發生這個錯誤。 請確定使用者或所屬的群組已對映至錯誤訊息中所提及的至少一個角色。 ibm-application-bnd.xmi/xml 檔中所定義的使用者至角色對映,優先於 server.xml 檔中所定義的對映。 請檢查這兩個資源,以確定定義了正確的對映。 請參閱 在 Liberty 中配置應用程式授權
CWWKS9104A: 使用者 {0} 授權失敗。
如果您對相同環境定義根目錄同時指定了 applicationwebApplication,會發生這個錯誤。 如果發生衝突,會忽略所定義的最新配置,並導致非預期的錯誤,例如 CWWKS9104A。
CWWKZ0013E: 不可能啟動兩個稱為 {0} 的應用程式,後面會出現非預期的安全行為,以及 CWWKS9104A 之類的錯誤訊息。
當您既在 server.xml 中利用 application 元素來指定您的應用程式,也在 dropins 資料夾中指定了這個應用程式,就會發生這個錯誤。 因此,會試圖安裝應用程式兩次,server.xml 檔中的安全配置有可能不生效。 如果要修正這個問題,您必須從 dropins 資料夾中移除您的應用程式,將它複製到另一個目錄中。 如果必須將它保留在 dropins 資料夾中,您必須在 server.xml 檔中,利用下列程式碼來停用應用程式監視:
<applicationMonitor dropinsEnabled="false"/>
未經鑑別的使用者可以存取我的 Servlet 或 JSP。
當鑑別失敗時,或當您的 Servlet 或 JSP 未受保護時,會建立一個主體為 UNAUTHENTICATED 的使用者(在 z/OS® 上是未經鑑別的 SAF 使用者)。 如果您沒有定義任何安全限制,或您將 EVERYONE 特殊主體對映至應用程式所需要的角色,未經鑑別的使用者可以存取您的 Servlet 或 JSP。 請檢閱 ibm-application-bnd.xmi/xmlserver.xml 檔中的使用者至角色對映。 請採用下列選項之一:
  • 如果您的 Servlet 或 JSP 未受保護,請新增安全限制到應用程式的部署描述子中。請參閱 鑑別
  • 如果您不想要任何未經鑑別的使用者存取您的應用程式,請從這個角色的對映中移除 EVERYONE 特殊主體。請參閱 在 Liberty 中配置應用程式授權
  • 如果無法將您的 Servlet 或 JSP 授權給某些使用者,請檢查 ibm-application-bnd.xmi/xmlserver.xml 檔,看看是誰對映至這個角色。 您可以將角色對映至使用者、群組或特殊主體。 如果您的角色是對映至 EVERYONE 特殊主體,任何使用者都會獲得存取權。 如果您的角色是對映至 ALL_AUTHENTICATED 特殊主體,任何已鑑別的使用者都會獲得存取權。 如果您想進一步限制能夠存取您的 Servlet 或 JSP 的人,請移除這些特殊主體。 最終,請檢查使用者是屬於哪個群組。 雖然使用者不一定有明確的存取權,但群組可能會對映至角色。 在這種情況下,請從已授權的群組中移除使用者,或從角色對映中移除群組。 請參閱 在 Liberty 中配置應用程式授權
單一登入 (SSO) 無法運作。
如果 SSO 無法運作,請確定使用相同 LTPA 金鑰、密碼及 webAppSecurity 元素之 ssoCookieName 屬性的不同 Liberty 伺服器,其「世界標準時間」(UTC) 相同,且共用使用者登錄。另外,如果記號到期,或以不一致的方式變更使用者登錄(例如:修改領域,或移除 Cookie 所代表的使用者)之後,從 Web 瀏覽器送出 Cookie,SSL 就會失敗,系統會提示使用者重新輸入認證資訊。請參閱 在 Liberty 中利用 LTPA Cookie 來自訂 SSO 配置
進行安全公用 API 的除錯。
即使未啟用安全,例如,未指定安全特性(appSecurity-1.0appSecurity-2.0zosSecurity-1.0),也會載入 WSSecurityHelperRegistryHelper。 如果未啟用安全,WSSecurityHelper.isServerSecurityEnabled()WSSecurityHelper.isGlobalSecurityEnabled() 方法都會傳回 false,RegistryHelper.getUserRegistry() 方法會傳回 null。

如果未啟用安全,可能不會載入其他安全公用 API 類別。 如果您試圖存取這些類別,並呼叫其中一個類別的方法,可能會出現 java.lang.NoClassDefFoundError 異常狀況。

如果要避免出現 java.lang.NoClassDefFoundError 異常狀況,您必須先呼叫 WSSecurityHelper.isServerSecurityEnabled()WSSecurityHelper.isGlobalSecurityEnabled() 類別來進行測試,以瞭解是否啟用了安全,然後只在啟用安全之時,才呼叫其他安全公用 API 類別。 請參閱Liberty 中的安全公用 API,以取得這個編碼技術的範例。

註: 這個行為與 WebSphere® Application Server 傳統版 不同。在 WebSphere Application Server 傳統版 中,不論是否啟用安全,都一律會載入所有類別。
無法鑑別含有 Unicode 字元的使用者
如果要鑑別名稱含有 Unicode 字元的使用者,您必須在伺服器 start 指令中新增下列 JVM 選項,將 Liberty 伺服器使用的字元編碼類型設為 UTF-8:
-Dclient.encoding.override=UTF-8
您也必須在登入頁面中指定 charsetpageEncoding。這裡的範例是在登入 JSP 頁面上指定下列參數:
<%@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)
當 OpenID Connect 或 OAuth 提供者使用「資料庫儲存庫」,來登錄使用某些 JDK 7 版本的用戶端時,便可能發生這個錯誤。

如果要避開這個問題,請升級至 JDK 7.1 版。

LDAP 疑難排解

這節說明一些常見的 LDAP 問題及您可以選擇的解決方案。

FFDC1015I: 已建立一個 FFDC 發生事件:javax.naming.ServiceUnavailableException: myldapserver.mycompany.com:636; socket closed com.ibm.ws.security.registry.ldap.internal.LdapRegistry 298
messages.log 中的這個訊息指出,無法呼叫到所配置的 LDAP 伺服器。 請檢查您的 LDAP 伺服器,確認它在執行中,且能夠從 Liberty 伺服器來存取它的 IP 位址。
javax.naming.CommunicationException: 簡式連結失敗: myldapserver.mycompany.com:636 [根異常狀況是 javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.g: PKIX 路徑建置失敗: java.security.cert.CertPathBuilderException: 找不到通往所要求之目標的有效憑證路徑]
如果您的 LDAP 伺服器啟用 SSL,且您未將 LDAP 伺服器的簽章者複製到 LDAPSSLSettings 元素所參照的信任儲存庫中,則與 LDAP 伺服器的連線會失敗並出現 SSL 信號交換錯誤。 請務必將 LDAP 伺服器的簽章者複製到您的信任儲存庫中。
javax.naming.CommunicationException: myldapserver.mycompany.com:389 [根異常狀況是 java.net.BindException: 位址已在使用中: connect]
這個訊息可能會出現在 FFDC 日誌中,指出本端伺服器可用的 Socket 已用完,當連接到您的 LDAP 伺服器時,可能會導致失敗。 請確定未使用 Socket,然後再試一次。
CWWKS1100A: 使用者 ID xxxxx 的鑑別不成功。 指定了無效的使用者 ID 或密碼
在負載繁重時,即使訊息中提及的使用者是 LDAP 伺服器上的有效使用者,伺服器也可能發生這個 FFDC 異常狀況。當使用 LDAP 配置時,您可以利用開發人員工具來新增 reuseConnection=false 內容,或將它停用。 如果要修正這個問題,請將這個內容設為預設值 true

SSL 疑難排解

這節說明一些常見的 SSL 問題及您可以選擇的解決方案。

CWWKS9105E: 無法判斷自動重新導向的 SSL 埠。
當您試圖存取重新導向到 SSL 埠的應用程式,但無法使用 SSL 埠時,會出現這個錯誤。 這個埠有可能因為遺漏 SSL 配置或 SSL 配置定義中的某些錯誤而無法使用。 請檢查 server.xml 檔中的 SSL 配置,以確定它存在,並且正確。 請參閱 利用 Liberty 來維護通訊安全
FFDC1015I: 已建立一個 FFDC 發生事件:" "java.lang.IllegalArgumentException: 配置不明、不完整:遺漏 ID 欄位 com.ibm.ws.config.internal.cm.ManagedServiceFactoryTracker aSyncReadNupdate。當試圖讀取配置及更新 ManagedServiceFactory 時,擲出異常狀況。 異常狀況 = java.lang.IllegalArgumentException: 配置不明、不完整:遺漏 ID 欄位" at ffdc_12.04.18_16.09.42.0.log
當配置中有 keystore 元素,但沒有 ID 欄位時,會發生這個錯誤。 如果您使用最低限的 SSL 配置,請將 ID 欄位設為 defaultKeyStore
如果您使用已設定 sslEnabled 但未指定 sslRef 值的 LDAP 使用者登錄,可能會出現異常狀況。
比方說,如下列範例所示,配置的 sslEnabled 設為 true,但沒有 sslRef 值:
<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" />
您必須輸入 sslRef 值。 如果您使用類似下列中的最低限的 SSL 配置:
<ltkeyStore id="defaultKeyStore" location="key.jks"
password="mypassword" />
sslRef 欄位必須設為 defaultSSLConfig

如果配置了自訂 SSL 配置,這個配置的名稱必須放在 sslRef 欄位中。

如果您使用 WebSphere Application Server 中的 JDK,而且您的 Liberty 伺服器已啟用 SSL,您可能會看到下列錯誤。
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)
發生這個錯誤是因為 Liberty 不支援 WebSphere Application Server SSL Socket Factory。您可以執行下列步驟,來避開此問題:
  • 建立含有下列兩個空項目的文字檔(例如,my.java.security):
    ssl.SocketFactory.provider=
    ssl.ServerSocketFactory.provider=
  • Liberty 伺服器建立 jvm.options
  • 將下列內容新增至 jvm.options 檔,內含指向您剛建立之文字檔的完整路徑:
    -Djava.security.properties=fullPathTo/my.java.security 
  • 如果您提高 my.java.security 檔的重複使用頻率,請將此檔案放在伺服器目錄中,之後您就可以使用類似如下的相對路徑:
    -Djava.security.properties=./my.java.security 

如需相關資訊,請參閱自訂 Liberty 環境

CORBA/IIOP 疑難排解

本節說明一些常見的 CORBA 問題,以及您可以選擇的解決方案。

如果您使用 WebSphere Application Server 中的 JDK,且您的應用程式使用 CORBA/IIOP 通訊,您可能會看到下列錯誤。
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) 
        ...

發生這個錯誤是因為 Liberty 不支援 WebSphere Application Server Object Request Broker (ORB) 攔截程式。如果要解決這個問題,您可以從 JDK 編輯 orb.properties 檔,使其不使用這些攔截程式。這個檔案可在 WebSphere <JAVA_HOME>/jre/lib 目錄中找到,不過,可能已被使用者 <USER_HOME> 目錄中的副本所置換。下列範例顯示 orb.properties 檔中必須註銷的字行:

# 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 & Plugins properties
#com.ibm.ws.orb.transport.ConnectionInterceptorName=com.ibm.ISecurityLocalObjectBaseL13Impl.SecurityConnectionInterceptor

記載和追蹤的疑難排解

本節說明記載和追蹤的一些常見問題。

java.util.logging -- Java 記載程式設計介面。
Liberty 不支援使用 logging.properties 檔來配置 java.util.logging。請使用 Java 程式碼(例如在已部署的應用程式或使用者特性中)來建立及新增 java.util.logging 處理程式、過濾器或格式製作程式。
由於 Liberty 伺服器會根據記載配置元素的 traceSpecification 屬性,來管理 java.util.logging 日誌程式層次,請避免使用 Logger.setLevel 方法。

JAX-WS 疑難排解

這節說明一些常見的 JAX-WS 問題及您可以選擇的解決方案。

當您在 Liberty 上部署 Web 服務應用程式時,發生 org.apache.cxf.bus.extension.ExtensionException。
如果您的應用程式已內嵌 CXF 程式庫及配置,且您想將應用程式部署到 Liberty,您必須確定已從 server.xml 檔中移除 jaxws-2.2 伺服器特性,以停用這個特性。
當您執行含有 Oracle JVM 的 IBM® 捷徑時,發生 java.lang.NoClassDefFoundError 異常狀況。
如果要使用 IBM 捷徑「Java XML 連結架構 (JAXB)」,您可以配置 com.ibm.xml.xlxp.jaxb.opti.level 自訂內容來控制 JAXB 解除配置(解除序列化)和配置(序列化)是否啟用最佳化方法。如果您在執行含有 Oracle JVM 的 IBM 捷徑 JAXB 時,發生 java.lang.NoClassDefFoundError 異常狀況,您可以將 com.ibm.xml.xlxp.jaxb.opti.level 內容值變更為 0 來關閉最佳化。 例如,您可以在指令行中使用 -Dcom.ibm.xml.xlxp.jaxb.opti.level=0 內容,或新增下面這一行到 jvm.options 檔中:
# 關閉 JAXB 最佳化
-Dcom.ibm.xml.xlxp.jaxb.opti.level=0
請參閱 Java 虛擬機器自訂內容頁面中,com.ibm.xml.xlxp.jaxb.opti.level 內容的相關資訊。
java.lang.NoClassDefFoundError:當您搭配 Oracle JVM 來執行 WebSphere Application Server 傳統版小型用戶端時,發生 com.ibm.CORBA.iiop.ORB 異常狀況。
當您試圖搭配 Oracle JVM 來執行 WebSphere Application Server 傳統版 小型用戶端,且 Liberty 已啟用 jaxws-2.2 特性時,會發生這個錯誤。 如果要解決這個問題,您可以依照下列方式,在執行 WebSphere Application Server 傳統版 小型用戶端時,使用 -Dcom.ibm.websphere.thinclient=true 內容:
java -Dcom.ibm.websphere.thinclient=true
     -cp <classpath_entries_including_tWAS_thinclient_jar> <WebServicesClientEntryClass> <any_more_parameters>
請參閱 PM39777: 使用 SOAP 連接器及 Sun JDK 的管理小型用戶端無法運作頁面中,com.ibm.websphere.thinclient 內容的類似資訊。
當您從 MTOM 服務中將二進位檔擷取到 MTOM 用戶端時,傳回空檔案。
當 MTOM 用戶端將二進位檔順利傳送到 MTOM 服務,但從 MTOM 服務擷取相同的二進位檔卻傳回空檔案,這時就發生這個情況。
作為暫行解決方法,您可以建立一個新的 DataHandler,然後填寫二進位檔內容來起始設定 DataHandler。 比方說,利用 FileDataStore 物件來讀取 I/O,傳回新建的 DataHandler,然後將 DataHandler 傳給其他 Web 服務。
...
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;
...
javax.xml.ws.soap.SOAPFaultException:當您搭配 Oracle JVM,以 xsd:gMonth 格式來使用 XMLGregorianCalendar 時,發生解除配置錯誤。
當您利用 XMLGregorianCalendar 類別,在用戶端將 gMonth 格式的常數儲存成 SOAP 要求的一部分,且在含有 Orcale JVM 的 Liberty 上啟用 jaxws-2.2 特性時,會發生這個錯誤。主要原因是 Oracle JVM 支援 xsd:gMonth 的新標準格式 --MM,而最新的 JAXB RI(參照實作)只支援 --MM-- 格式。
如果要解決這個問題,您可以將用戶端和伺服器兩端應用程式的 Oracle JVM 變更為 IBM JVM。
當您解析 wsdlLocation 屬性所指定的 WSDL 檔時,發生 java.io.FileNotFoundException。
當您依照程式碼 wsdlLocation = "file:/WEB-INF/wsdl/a.wsdl" 指定 WSDL 檔,且將 WSDL 檔包裝在您的應用程式內時,會發生這個錯誤。 如果您想要參照應用程式所包裝的 WSDL 檔,您必須在 @WebService@WebServiceProvider@WebServiceClient@WebServieRef 註釋所定義的 wsdlLocation 屬性中使用相對 URI。
wsdlLocation 屬性的相對 URI 必須是下列值之一:
  • wsdlLocation = "/WEB-INF/wsdl/a.wsdl"
  • wsdlLocation = "WEB-INF/wsdl/a.wsdl"
messages.log 檔中出現許多「建立服務」訊息。
當您在產生的用戶端 Stub 類別中呼叫 getPort 或相關的方法時,會發生這個情況。Liberty 是以預設記載配置來配置,所有參考訊息都會寫入 messages.log 檔中。可能會出現許多類似下列的訊息:
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
如果要抑制這些參考訊息,您可以依下列方式變更 server.xml 檔中的記載配置:
<logging traceSpecification="org.apache.cxf.*=warning=enabled"/>
SOAPFaultException:給定的 SOAPAction test 不符合用戶端應用程式傳送「SOAP 動作」時所發生的作業。
註: test 是要求 HTTP 標頭中的 soapAction 屬性值。
SOAP Web 服務中的每一個作業都可以與一個「SOAP 動作字串」相關聯,如同在 WSDL 連結中或透過註釋一樣。 Web 服務用戶端會隨要求傳送「SOAP 動作」字串作為標頭,以符合 Web 服務提供者的作業。在下列任一情況下,會顯示此錯誤訊息:
  • 當用戶端傳送的 SOAP 動作不符合作業的 SOAP 動作時。
  • 當您使用 WebSphere Application Server 傳統版 作為 JAX-WS 用戶端、使用 Liberty 作為 JAX-WS 服務,且 WSDL 檔案中所定義的 soapAction 等於空白值 "" 時。
如果要解決此問題,請執行下列動作:
  • 確定您為 Web 服務用戶端和服務提供者指定的 SOAP 動作相同。
  • 針對 WSDL 檔案中定義的 soapAction 屬性提供有效值,或者不要在 WSDL 檔案中使用 soapAction
當您使用 Service.create() 方法來建立服務時,發生 javax.xml.ws.WebServiceException。
如果您使用 Service.create() 方法來建立服務,但未提供 WSDL 文件,則會發生這項錯誤。如果您要使用 Service.create() 來建立服務並使用 getPort()方法來取得埠號,您必須使用 addPort() 方法來提供連結資訊。
以下提供如何使用 addPort() 方法的範例程式碼:
QName serviceName = new QName("http://test.com/wssvt/acme/InsBusiness/", "MTOM11Service");
QName portName = new QName("http://test.com/wssvt/acme/InsBusiness/", "MTOM11Port");

// Setup the necessary JAX-WS artifacts
Service svc = Service.create(serviceName);
// Add the port in the service instance
svc.addPort(portName, SOAPBinding.SOAP11HTTP_MTOM_BINDING, mtom11URL);

port = svc.getPort(portName, MTOMInterface.class);
當 @WebResult 註釋中的 name 屬性與 WSDL 文件中的 name 元素不同時,會傳回 Null 回應。
發生這個問題的情況:當您使用 SEI 類別來定義 @WebResult 註釋的 name 屬性,且 SEI 提供的 WSDL 位置如下:
@WebService(wsdlLocation="WEB-INF/wsdl/WebServiceIfc.wsdl")
public interface WebServiceRuntimeIfc {
        @WebMethod
        @WebResult(name="nononoreturn")
        public String echo (String parm);
}
但是所提供的 WSDL 文件中的 XML 元素宣告如下:
<xs:element name="echoResponse">
		<xs:complexType>
				<xs:sequence>
						<xs:element name="return" type="xs:string" minOccurs="0"/>
				</xs:sequence>
		</xs:complexType>
</xs:element>
那麼,呼叫 echo() 方法時,Web 服務用戶端會取得 NULL 回應。
如果要解決這個問題,請確定 @WebResult 註釋的 name 屬性符合 WSDL 文件中的 name 元素值。
JAX-WS 用戶端應用程式無法從伺服器端取得 WSDL 文件變更。
當 Web 服務用戶端和服務提供者位於 Liberty 上的兩個不同應用程式中,且用戶端需要從服務提供者動態擷取 WSDL 文件時,會發生此問題。因為 Liberty 會在第一次存取 WSDL 文件時快取 WSDL 定義,這與 WebSphere Application Server 傳統版 中的行為不同。 透過快取 Liberty 中的 WSDL 定義,應用程式可以避免經常連接及剖析 WSDL 文件。
如果要解決這個問題,您必須重新啟動用戶端應用程式,以便能夠重新載入更新的 WSDL 定義。
WSDL 匯入期間發生 JAXB 警告
當您匯入 WSDL 檔時,可能會出現下列警告訊息。
[WARNING] unknown extensibility element or attribute "wsdl" (in namespace "http://www.w3.org/2000/xmlns/" (http://www.w3.org/2000/xmlns/%27) )

WS-Security 疑難排解

這節說明一些可用來解決 WS-Security 問題的常見解決方案。
  1. 檢查 server.xml 檔,確定已正確配置必要的 JAX-WS (jaxws-2.2) 和安全 (appSecurity-2.0) 特性。
  2. 如果要利用 WS-Security 來保護您的 Web 服務應用程式,您的 JAX-WS 應用程式必須包含內嵌了「WS-Security 原則」的 WSDL 檔。 在 wsdl:binding 及/或 wsdl:operation 區段中,必須有指向內嵌 WS-Security 原則的 PolicyReference。
  3. 如果您利用回呼處理常式來擷取密碼以產生 UsernameToken,或從金鑰儲存庫檔中擷取私密金鑰的密碼,密碼回呼處理常式必須包裝及部署成 Liberty 中的一項使用者特性。

啟用 WS-Security 追蹤

如果錯誤訊息中的資訊無法判斷問題原因,您可以利用 Liberty 追蹤和記載機能來收集 WS-Security 元件的追蹤。請參閱 Liberty:追蹤和記載

您可以利用下列追蹤字串來收集追蹤,以進行 WS-Security 失敗除錯:
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

這節說明一些常見的 WS-Security 問題及您可以選擇的解決方案。

org.apache.cxf.ws.policy.PolicyException:無法滿足任何原則替代方案。
通常是在 server.xml 檔未定義 WS-Security 特性 wsSecurity-1.1 時,發生這個錯誤。 如果要避免這個錯誤,您必須依照下列方式,在 server.xml 檔中定義 wsSecurity-1.1 特性:
<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:沒有回呼處理常式,也沒有可用的密碼。
當 WS-Security 執行時期無法擷取產生 UsernameToken 或從金鑰儲存庫存取私密金鑰所需要的密碼時,會發生這個錯誤。 如果要避免這個錯誤,請檢查下列配置:
  1. 確定在 server.xml 檔中,已將密碼回呼處理常式特性 wsseccbh-1.0 定義為一項使用者特性:
    <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. 確定回呼處理常式內容 ws-security.callback-handler 已定義在 server.xml 檔的 <wsSecurityClient> 或 <wsSecurityProvider> 元素中:
    ws-security.callback-handler="<full class name of the callback handler>"
    
    範例:
    ws-security.callback-handler="com.ibm.ws.wssecurity.example.cbh.CommonPasswordCallback"
  3. 確定密碼回呼處理常式會傳回 server.xml 檔指定的使用者名稱或金鑰別名的正確密碼。 密碼必須是明碼,沒有編碼或加密。
org.apache.ws.security.WSSecurityException:簽章沒有涵蓋必要的元素 (soap:Body)。
當 Web 服務提供者應用程式預期會簽署要求訊息中的 SOAP 主體,但收到的 SOAP 訊息沒有簽署 SOAP 主體時,會發生這個錯誤。 如果要避免這個錯誤,請確定您的 Web 服務用戶端配置了符合 Web 服務提供者原則的正確 WS-Security 原則。
org.apache.ws.security.WSSecurityException:簽章或解密無效。
當 WS-Security 執行時期無法驗證簽章,或無法將收到的 SOAP 訊息其中已加密的訊息組件進行解密時,會發生這個錯誤。 如果要避免這個錯誤,請確認您在 server.xml 檔的 <wsSecurityClient> 和 <wsSecurityProvider> 元素中配置 WS-Security 時,使用正確的金鑰。 如果 Web 服務用戶端利用 Bob 的公開金鑰來加密訊息組件,Web 服務提供者必須有權存取 Bob 的私密金鑰來將訊息解密。同樣地,如果 Web 服務用戶端利用 Alice 的私密金鑰來簽署訊息組件,Web 服務提供者必須利用 Alice 的公開金鑰來驗證簽章。
org.apache.cxf.ws.policy.PolicyException:無法滿足這些原則替代方案。
當 WS-Security 執行時期無法利用配置來處理這個要求的 WS-Security 原則順利處理送入的 SOAP 訊息時,會發生這個錯誤。 如果要避免這個錯誤,請查看這個異常狀況後面的訊息,以判斷造成這個異常狀況的特定 WS-Security 原則主張。 比方說,日誌檔可能會包含下列訊息:
原因:org.apache.cxf.ws.policy.PolicyException:無法滿足這些原則替代方案:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}AsymmetricBinding: 加密演算法不符合需求
{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)
在這種情況下,會因為 Web 服務用戶端所用的加密演算法不符合 AlgorithmSuite 主張所指定的加密演算法而發生這個錯誤。 Web 服務用戶端和 Web 服務提供者兩者的 WS-Security 原則所指定的演算法套組,必須指定相同的加密演算法。
javax.xml.ws.soap.SOAPFaultException:訊息過期(WSSecurityEngine:時間戳記無效。訊息的安全語意已過期)。
當訊息時間戳記過期,或建立訊息時使用未來的時間戳記,就會發生這個訊息。

效能的疑難排解

本節說明一些常見的效能問題,以及您可以選擇的解決方案。

您的應用程式監視器使用高 CPU 使用率。

如果您的應用程式監視器在 apps/ 目錄底下有很多檔案,而且輪詢頻率太高,就會發生此錯誤。

如果要避免此問題,您可以做一些變更。

  1. applicationMonitor 元素中增加 pollingRate 屬性的值。
  2. 更新 server.xml,以併入 applicationMonitor 元素,使其含有非 polledupdateTrigger
    server.xml
    <applicationMonitor updateTrigger="mbean" /> 
  3. 減少 apps/ 目錄底下的檔案數目。

如需 applicationMonitor 元素的相關資訊,請參閱控制動態更新

疑難排解群體

本節說明群體問題,以及您必須套用的解決方案。

java.lang.IllegalArgumentException: CWWKX0219E: MBean 'WebSphere:feature=collectiveController,type=CollectiveRepository,name=CollectiveRepository' 並無名為 'retrieveMemberRootCertificate' 的作業
具有 collectiveMember-1.0 特性的伺服器(為一個成員),無法向具有 collectiveController-1.0 特性的伺服器 (為一部控制器,且 Liberty 層次較低)登錄。比方說,使用 Liberty 這個測試版層次的成員本身無法向使用 Liberty 8.5.5.2 版的控制器登錄其本身。

根據預設記載,此問題會以「首次失敗資料擷取 (FFDC)」形式報告於成員的 FFDC 日誌中。

如果要修正問題,您必須將控制器移至與該成員相同或更高的 Liberty 層次。

SAML 的疑難排解

本節說明 SAML 問題,以及您必須套用的解決方案。

java.lang.ArrayIndexOutOfBoundsException: 陣列索引超出範圍:0
當您透過自發「服務提供者 (SP)」起始的要求,嘗試多次登入,卻沒有移除「身分提供者記號 (IdP)」,就可能發生此異常狀況。
若要避免此問題,請在相關的自發 server.xml 檔中,新增 <httpSession invalidateOnUnauthorizedSessionRequestException="true" />
java.lang.IllegalStateException:CWWKS0010E: 在取得呼叫端主體 (principal) 時,發現呼叫端主體 (subject) 有多個主體 (principal) 的類型是 WSPrincipal。 主體 (subject) 中只能有一個 WSPrincipal。這些 WSPrincipal 的名稱是:{0}
如果 SAML 使用者先前直接登入內部部署的使用者登錄,就可能發生此異常狀況。如果要避免此問題,SAML 使用者不得直接登入內部部署的使用者登錄。

REST API 探索的疑難排解

如果從遠端呼叫 IBM REST API 探索瀏覽器的「試用一下」選項,並因回應碼等於 0 而失敗,請確定已將完整的主機名稱或 IP 位址傳回到「IBM REST API 探索瀏覽器」中與 GET、PUT、POST 或 DELETE 作業相關聯的 Curl 和要求 URL 中。如果完整的主機名稱或 IP 位址不在 Curl 和要求 URL 中,請完成下列動作:

  1. server.xml 中新增 variable 元素,並指定完整的主機名稱。以下範例是在 server.xml 檔中新增 variable 元素,以指定完整的主機名稱:
     <httpEndpoint host="*" httpPort="9080" httpsPort="9443" id="defaultHttpEndpoint"/>          
    <variable name="defaultHostName" value="developer.rtp.raleigh.ibm.com"/>
  2. 驗證已將完整的主機名稱傳回到「IBM REST API 探索瀏覽器」中與 GET、PUT、POST 或 DELETE 作業相關聯的 Curl 和要求 URL 中如需相關資訊,請參閱設定 Liberty 伺服器的預設主機名稱,並閱讀 IBM InfoSphere Information Server 11.3.1 版產品說明文件中有關配置網路的說明。

指示主題類型的圖示 參照主題

檔名:rwlp_trouble.html