|
|
|
|
|
|
|
信頼性のないクライアントから受信した SOAP リクエストを検証するためのメカニズムが必要です。WebLogic Server では、WebLogic Server Web サービスで受信したリクエストを検証するためのメカニズムが提供されるようになりました。
ただし、検証によってパフォーマンスが低下するおそれがありますので、注意して使用してください。受信した SOAP リクエストは、以下のいずれかの方法で検証できます。
サーバ上のすべてのサービスの検証が有効にするには、サーバの起動時に次のコマンドライン パラメータを使用する。
-Dweblogic.wsee.validate_request=true
特定の Web サービスの検証を有効にするには、weblogic-webservice.xml に <validate-request>true</validate-request> を追加する。次に例を示します。
<?xml version='1.0' encoding='UTF-8'?>
<weblogic-webservices xmlns="http://www.bea.com/ns/weblogic/90";;;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";;;>
<webservice-description> <webservice-description-name>HelloWorld</webservice-description-name>
<port-component-name>HelloWorldServiceImplSoapPort</port-component-name>
<service-endpoint-address> <webservice-contextpath>hello</webservice-contextpath> <webservice-serviceuri>/test</webservice-serviceuri>
</service-endpoint-address>
<!-- Note this validate request tag -->
<validate-request>true</validate-request>
</webservice-description>
|
|
|
|
|
WebLogic Server では、JAX-RPC 1.1 仕様の要件に従い、Sparse Array および Partially Transmitted Array はサポートされていません。
|
|
|
|
|
document-literal wrapped 型の Web サービスでは、入力パラメータまたは戻り値としての XMLBean データ型の使用がサポートされていません。
|
|
|
|
|
WebLogic Server 9.0 クライアントでは、サーバから送信されたクッキーを送信できませんでした。
この問題は解決されています。現在では、クッキーは正しく処理され、クライアント セッションが保持されます。
|
|
|
|
|
以下は、jwsc、wsdlc、および clientgen に適用されます。
Web サービスのインタフェース、実装、およびパラメータ型のパッケージ名に大文字が使用されていると、一部のオペレーティング システムでビルドと実行に問題が生じることがあります。
パッケージ名には小文字を使用することを強くお勧めします。
|
|
|
|
|
クライアントからサービスに複合型のインスタンスを送信した場合に、サービス側で受信したインスタンスがエコー バックされます。複合型に any 要素が含まれていて、 any の内容にデータが格納されている場合、そのデータがサービスに渡されません。
|
|
|
|
|
Web サービス記述言語 (Web Services Description Language : WSDL) のコンパイラでシリアライズ可能なデータ型が生成されないため、データがリモートの EJB に渡されない、または JMS 送り先に格納されません。
|
|
|
|
|
WLHttpsTransport で次のエラーが発生します。
AsyncReponseService returned a 404
|
|
|
|
|
非同期応答サービスは https プロトコルの転送をサポートしていませんでした。その結果、非同期応答が https 転送を介して返送された場合、応答を処理するサービスがデプロイされていないため、404 エラーが発生しました。
非同期応答サービスに https プロトコル転送のサポートが追加されました。
|
|
|
|
|
Web サービスでパラメータとして XMLObject を使用すると、実行時にクライアントからそのサービスにアクセスしようとしたときに java.lang.IncompatibleClassChangeError 例外が送出されます。
|
|
|
|
|
jwsc Ant タスクが入力部分のない document-literal-wrapped の Web サービスの WSDL を生成した結果、空の本文を持つ要求エンベロープが生成されます。
|
|
|
|
|
デフォルトの Auth.xml のような抽象 ID アサーションを持つセキュリティ ポリシーを使用する場合、WebServiceSecurity MBean で UseX509ForIdentity 属性が有効になっているかどうかにかかわらず、サポートされる ID トークンとして X509 トークンが含まれます。
UseX509ForIdentity 属性が true に設定されている場合に限り、X509 トークンはサポートされる ID のトークンとして挿入されます。
|
|
|
|
|
javax.xml.transform.Source のアタッチメントが、ソース xml に非 ASCII 文字が含まれる場合に機能しません。
|
|
|
|
|
暗号化されたデータに「&」などの特殊文字が含まれている場合、署名参照の検証が失敗します。
|
|
|
|
|
JMS 転送を通じて Web サービスを呼び出す場合に、リクエストまたは添付ファイル内の非 ASCII データが変更される可能性があります。
アプリケーションがリクエストを JMS BytesMessage として送信できるようにします。デフォルトは、以前のリリースで使用されているメッセージ タイプの TextMessage のままです。非 ASCII データまたはバイナリの添付ファイルを送信する必要があるアプリケーションでは BytesMessage を使用できます。JAX RPC スタブには、JMS メッセージ タイプを設定するためのプロパティがあります。ポートを取得したら、以下のいずれかの方法で JMS メッセージ タイプを BytesMessage に設定できます。
((Stub)port)._setProperty(WLStub.JMS_TRANSPORT_MESSAGE_TYPE, WLStub.JMS_BYTESMESSAGE) weblogic.wsee.util.JmsUtil.setJmsTransportBytesMessage((Stub)port)
応答 (同期または非同期) はリクエストと同じメッセージ タイプで送信されます。
コールバックを BytesMessage として送信するには、アプリケーションでコールバック スタブの JMS_TRANSPORT_MESSAGE_TYPE プロパティを設定する必要があります。
|
|
|
|
|
WebLogic Server 8.1 形式 (バージョン 1) の会話サービスでは、クライアントが会話 ID を明示的に認識してエコーする必要があります。会話 ID はアプリケーションまたはクライアントサイド サーバによって割り当てられますが、サービスの実際の提供元は認識されません。リリース 9.0 以降のバージョン 2 の会話サービスは WS-Addressing に準拠しており、会話 ID が自動的にサービスにエコー バックされます。会話 ID はサーバ サイドで割り当てられ、その中にルーティング情報が埋め込まれます。8.1 形式の会話クライアントがクラスタ化環境にある 9.x サーバと対話する場合、クラスタでは、リクエストを正しいサーバにルーティングするための十分な情報が得られません。
解決策は、クラスタ全体のシングルトン サービス (パス サービス) を使用して、8.1 形式のルーティング情報を記録することです。
そのためには、追加のコンフィグレーションが必要です。パス サービスをコンフィグレーションして、クラスタ内のいずれかのサーバにデプロイする必要があります。この解決策では、スケーラビリティやシングル ポイント障害に関して 8.1 よりも後退することが確認されています。パス サービスに組み込まれたキャッシュ機能と、WLS のサーバ移行機能によって、後退は若干緩和されます。
|
|
|
|
|
あらかじめ用意されたポリシー、ライブラリ ポリシー、およびユーザ定義のポリシーがすべて同じ名前を持つ場合に、誤った順序でロードされました。ユーザ定義のポリシーが優先されるはずですが、ライブラリ ポリシーが先にロードされました。
|
|
|
|
|
WebLogic Server 9.2 より前のリリースでは、 clientgen は、WSDL の記述で別の配列の 1 次元配列として定義されている配列を処理できませんでした。
<s:complexType name="ArrayOfArrayOfString">
<s:complexContent>
<s:restriction base="enc:Array">
<s:sequence>
<s:element name="ArrayOfString"
type="enc2:ArrayOfString"
minOccurs="0"
maxOccurs="unbounded" />
</s:sequence>
<s:attribute ref="enc:arrayType"
wsdl:arrayType="enc2:ArrayOfString[]" />
</s:restriction>
</s:complexContent>
</s:complexType>
<s:complexType
name="ArrayOfArrayOfArrayOfArrayOfString">
<s:complexContent>
<s:restriction base="enc:Array">
<s:sequence>
<s:element
name="ArrayOfArrayOfArrayOfString"
type="enc2:ArrayOfArrayOfArrayOfString"
minOccurs="0"
maxOccurs="unbounded" />
</s:sequence>
<s:attribute ref="enc:arrayType"
wsdl:arrayType=
"enc2:ArrayOfArrayOfArrayOfString[]"/>
</s:restriction>
</s:complexContent>
</s:complexType>
|
|
|
|
|
JWSC はビルド プロセス中に作成された一時ファイルを削除しませんでした。
|
|
|
|
|
Web サービス クライアントが HTTPS を使用して、HTTP 転送のみをサポートする Web サービスにアクセスしようとすると、「 Invalid/unknown SSL header was received」というエラーが発生します。
HTTPS をサポートする Web サービスをビルドするには、JWS で @WLHttpTransport アノテーションの代わりに @WLHttpsTransport アノテーションを使用します。
|
|
|
|
|
WebLogic Server 9.2 より前のリリースでは、 clientgen は、次のような形式で型が表現されている多次元配列を処理できませんでした。
<complexType name="ArrayOfString2D">
<complexContent>
<restriction base="soapenc:Array">
<attribute ref="soapenc:arrayType"
wsdl:arrayType="string[][]"/>
</restriction>
</complexContent>
</complexType>
ここで、 wsdl:arrayType は次の形式で表現されています。
|
|
|
|
|
9.1 では、WebLogic Server は WSDL の次のような箇所に WS-Policy をアタッチできます。 wsdlPort、 wsdlBindingOperation、 wsp:PolicyReference WSDL 拡張を持つ wsdlBindingOperation の入力または出力メッセージ。
現在は、WSDL 1.1 仕様および WS-PolicyAttachment 仕様に従って、次の箇所に WS-Policy をアタッチできます。 wsdl:portType、 wsdl:binding、 wsdl:operation、 wsdl:operation/wsdl:input、および wsdl:operation/wsdl:output。
|
|
|
|
|
存在しない ws-policy への参照が含まれる WSDL ファイルが読み込まれたときにエラーが報告されません。
|
|
|
|
|
WebLogic Server 9.2 より前のリリースでは、クライアントのシステム クロックがサーバのシステム クロックよりわずかに進んでいる場合、同期化の小さな差異 (クロック精度よりも小さい差異) に対して、断続的に以下のタイムスタンプ エラー メッセージが発行されました。
Message Created time in the future
たとえば、clockPrecision 設定が 1 分 (デフォルト) に設定されていて、クライアントのクロックがサーバのクロックより 40 秒進んでいる場合、このメッセージが 40/60 または 2/3 の割合で送出されました。
clockPrecision プロパティは非推奨になり、より直感的な clockSkew プロパティで置き換えられました。ClockSkew は clockPrecision のように (上記の説明の 2/3 のような) 確率的な性質のプロパティではありませんが、「サーバのクロックとクライアントのクロックの許容される差異」という同様の概念を表します。
|
|
|
|
|
Administration Console または WLST を使用してタイムスタンプ設定を変更した場合は、アプリケーションを再デプロイする必要があります。
|
|
|
|
|
WebLogic Server 9.0 では、WebLogic Server 8.1 で作成されたクライアントによって生成された暗号化済みの SOAP メッセージをサーバが処理できず、以下の例外が発生します。
weblogic.xml.dom.marshal.MarshalException: Unrecognized child element in SecurityTokenReference
WebLogic Server では、 SecurityTokenReference ノードで X509Data がない場合でも X509IssuerSerial を使用できるようになりました。
|
|
|
|
|
プロキシを介して動的に取得する場合に、WSDL アドレスの場所の SSL ポートが正しく設定されていません。
プロキシの背後にある内部サーバのアドレスではなく、クラスタ MBean または Web サーバ MBean で設定されているホストと HTTPS ポートになるように、アドレスを正しく設定します。
|
|
|
|
|
Web サービスの呼び出しを許可されるロールを指定するために、 @RolesAllowed、 @RolesReferenced、または @RunAs アノテーションを (クラス レベルで) 使用している Web サービスがデプロイされている場合、Web サービスにアクセスする側 (動的 WSDL を含む) はすべて、そのロールにマップされているユーザとして認証を受ける必要があります。
クライアント アプリケーションは HttpTransportInfo を使用して認証できます。しかし、clientgen には自身を認証する方法がありません。
|
|
|
|
|
HTTPS の使用を強制するために @UserDataConstraint アノテーションを使用している Web サービスがデプロイされている場合、Web サービスにアクセスする側 (動的 WSDL を含む) はすべて、サーバの信頼された証明書を含む、信頼された証明書のリストを格納したトラスト ストアを指定する必要があります。
Web サービスを呼び出すクライアント アプリケーションは、スタブ内にトラスト マネージャを定義することで、信頼された証明書をリストできます。ただし、clientgen には現在そのための方法がありません。
信頼された関連するプロパティを以下のように設定します。
<clientgen
wsdl="https://${wls-ssl-server}/HttpsWeb/
HttpsWebService?WSDL" destDir="${clientclasses.dir}" packageName="ssl.web.client">
<sysproperty key="javax.net.ssl.trustStore" value="${stage.dir}/DemoTrust.jks"/> <sysproperty key=
"weblogic.wsee.client.ssl.
stricthostchecking"
value="false"/> </clientgen>
|
|
|
|
|
WebLogic Server 9.2 より前では、EJB 実装の Web サービスで @UserDataConstraint アノテーションはサポートされていません。
@UserDataConstraint アノテーションを以下のように設定できるようになりました。
@WLHttpsTransport
(portName="HttpsEjbPort",
contextPath="HttpsEjb",
serviceUri="HttpsEjbService") @UserDataConstraint(transport=UserDataConstraint.Transport.CONFIDENTIAL)
public class HttpsEjbService implements SessionBean {
この構文では、HttpsEjbService へのアクセスを HTTPS プロトコルのみに制限しています。
|
|
|
|
|
CDATA DOM ノードにある MS Windows 形式の改行「 \r\n」が「 
」に正規化されましたが、SOAP メッセージでは「 \n」として出力されませんでした。そのため、受信側で別の正規化が行われて、署名検証が失敗しました。
|
|
|
|
|
WebLogic Server 9.2 より前のリリースでは、Web サービスで複雑な機能 (会話など) が使用される場合は、EJB ベースの Web サービスとしてパッケージ化されていました。WebLogic Server 9.2 では、複雑な Web サービスはサーブレット ベースの Web サービスとしてパッケージ化されます。
9.2 Web サービスを EJB モジュールとしてパッケージ化することを想定しているビルド スクリプトがある場合は、Web サービスをサーブレット モジュール ( WAR ファイル) としてパッケージ化するようにスクリプトを変更します。
|
|
|
|
|
WebLogic Server 9.1 では、 RolesReferenced アノテーションをコンフィグレーションするときに link 属性が必要です。次に例を示します。
@RolesReferenced(@SecurityRoleRef
(role = "admin", link = "Admin" ))
|
|
|
|
|
WebLogic Server 9.1 では、 RunAs アノテーションで mapToPrincipal 属性を設定する必要があります。次に例を示します。
@RunAs(role="user", mapToPrincipals="foo")
mapToPrincipals 属性は省略可能になりました。指定されていない場合は、デフォルトのセキュリティ ロールがデフォルトで設定されます。
|
|
|
|
|
プロキシ サーバで、サーバ起動時に非同期応答サービスが自動的にデプロイされた場合、以降のトラフィックは、プロキシ サーバが代理となっているサーバ上の非同期応答サービスにルーティングされていませんでした。代わりに、トラフィックをプロキシ サーバ自身が消費していました。
非同期応答サービスをデプロイしないようにするには、 weblogic.wsee.skip.async.response プロパティを true に設定します。
|
|
|
|
|
JAX-RPC 1.1 仕様では、バイト配列の Java から XML へのマッピングは xsd:base64Binary と指定されています。しかし、WebLogic Server 9.2 より前のリリースでは、 byte[] に対して生成されるスキーマ型が JAX-RPC 1.1 に準拠していませんでした。
JWSC を使用して、パラメータまたは戻り値の型として byte[] を使用するメソッドが含まれるクラスから Java Web サービスを開始した場合、 byte[] 引数に対応して生成された WSDL 型が、以下のように正しくありませんでした。
<xs:complexType name="ArrayOfbyte_literal">
<xs:sequence>
<xs:element maxOccurs="unbounded"
minOccurs="0"
name="byte"
nillable="false" type="xs:byte"/>
</xs:sequence>
</xs:complexType>
以下のように、 ArrayOfbyte_literal 型は document-literal-wrapped のオペレーション ラッパー要素で型として使用されました。
<xs:element
name="echoPrimitiveByteArray2Response">
<xs:complexType>
<xs:sequence>
<xs:element name="return"
type="arrayOfbyte_literal"/>
</xs:sequence>
</xs:complexType>
</xs:element>
|
|
|
|
|
JWSC は、JAX-RPC 1.1 に従って、 byte[] に対して xsd:base64Binary を生成するように変更されました。
<xs:element
name="echoPrimitiveByteArray2Response">
<xs:complexType>
<xs:sequence>
<xs:element name="return"
type="xs:base64Binary"/>
</xs:sequence>
</xs:complexType>
</xs:element>
したがって、これらの生成済みサービスを使用している JWS クライアントは、新しい WSDL を使用して JWS から再生成する必要があります。
|
|
|
|
|
WebLogic Server 9.2 では、親 Web サービスの対象ネームスペースに適合しないパッケージを持つカスタム例外を、コールバックで使用することはできません。
コールバックで使用されるカスタム例外は、親 Web サービスの対象ネームスペースに適合するパッケージに入れるようにしてください。
|
|
|
|
|
エンコーディングが RPC LITERAL の場合、WebLogic Server は SOAP12 を適切に処理しません。
|
|
|
|
|
JMS サーバ経由の SOAP メッセージの送信にクラスタ アドレスが使用される場合、WebLogic Server では例外が発生していました。
|
|
|
|
|
プロキシ サーバを使用している環境では、JMS 転送を使用できません。これは、JMS 転送の場合は Web サービス クライアントが常に t3 プロトコルを使用して Web サービスに接続するのに対し、プロキシ サーバでは HTTP/HTTPS しか受け付けられないためです。
|
|
|
|
|
RPC SOAP バインディングを使用して Workshop for WebLogic 8.1 アプリケーションが WebLogic Server 9.1 Web サービスを呼び出す場合は、 WSSecurityException が発生していました。
|
|
|
|
|
handleRequest から false が返されるたびに、ハンドラ応答チェーンがサービス エンドポイントに届いていました。
ハンドラ応答チェーンは、現在のハンドラから開始し、サービス エンドポイントには届きません。
|
|
|
|
|
既存のホルダ クラス名 FooArrayHolder と予期されるホルダ クラス名 ArrayOfFoosHolder との不一致のため、Web サービスのデプロイメントが失敗し、 ClassNotFoundException が発生していました。
既存のホルダ クラス名が、予期されるホルダ クラス名 ArrayOfFoosHolder に変更されました。
|
|
|
|
|
ParserFactory を使用して SAX パーサ インスタンスを作成しようとすると、 NullPointerException が発生していました。
|
|
|
|
|
Web サービス クライアントがユーザ定義のクラスの戻り値を使用して JBoss Web サービスを呼び出す場合は RemoteException が発生し、そのユーザ定義のクラスにはユーザ定義のクラスの配列であるフィールドがありました。
|
|
|
|
|
Web サービス パラメータとして複合型 http://www.w3.org/2001/XMLSchema{schema} を使用する WSDL の処理中に clientgen が失敗します。
|
|
|
|
|
大文字/小文字が混在するパッケージ名を使用してコールバック インタフェースを定義している Web サービスは、 jwsc によるコンパイルに失敗します。
小文字のパッケージでコールバック インタフェースを作成します。
|
|
|
|
|
WebLogic Server 9.0 および 9.1 で、jwsc タスクは入力パラメータとして XmlObject を処理できませんでした。
|
|
|
|
|
信頼性のある一方向の Web サービス呼び出しを行う場合は、匿名のコールバックから信頼性のあるメッセージの同期の確認応答が提供されていませんでした。
WSRM SequenceAcknowledgement メッセージにより、信頼性のあるメッセージの同期の確認応答が有効になっています。
|
|
|
|
|
JWSC で、WSDL のデフォルト URL として http://localhost:7001 が生成されていました。
この問題は解決されています。UserDataConstraint の値として INTEGRAL または CONFIDENTIAL が指定されている場合は、WSDL のデフォルト URL として https://localhost:7002 が生成されます (これはセキュアな URL です)。
|
|
|
|
|
WebLogic Server 9.2 はコールバック Web サービスで JAX RPC ハンドラをサポートしません。
WebLogic Workshop 8.1 で作成された Web サービスで JAX RPC ハンドラが使用されていた場合、そのアプリケーションは、コールバック ハンドラ機能を使用しないように再設計する必要があります。
|
|
|
|
|
wsrp-wsdl-template.wsdl を編集するには、 wlp-wsrp-producer-web-lib.war から web-app に以下のサポート ファイルをコピーする必要があります。
wlp_wsrp_v11_types.xsd wlp_wsrp_v1_types.xsd wsrp_v1_full.wsdl wsrp_v1_types.xsd wsrp-wsdl-template.wsdl wlp_wsrp_v1_bindings.wsdl wsrp_v1_bindings.wsdl wsrp_v1_interfaces.wsdl wsrp-wsdl-full.wsdl xml.xsd |
|
|
|
|
ANT クラスパスに weblogic.jar が追加されていない場合は、ビルド プロセス中に jwsc ANT タスクが失敗し、 ClassNotFoundException が発生していました。
|
|
|
|
|
WebLogic Server 9.2 では、添付ファイル付き SOAP メッセージをストリーミングする場合にチャンク転送エンコーディングをサポートしていません。
|
|
|
|
|
ANT クラスパスに weblogic.jar が追加されていない場合は、ビルド プロセス中に WSDLC WebLogic Web サービス ANT タスクが失敗し、 FactoryConfigurationError が発生していました。
|
|
|
|
|
JWS で @WLHttpsTransport を使用すると WS-I に準拠した wsdl が生成されません。
@WLHttpsTransport は非推奨になりました。HTTPS 転送のみを受け付けるように JWS エンドポイントを制限する必要がある場合は、 @WLHttpTransport および @UserDataConstraint の両方を使用します。
|
|
|
|
|
WebLogic Server 9.2 はコールバック Web サービスでメッセージ レベルのセキュリティをサポートしません。
WebLogic Workshop 8.1 で作成された Web サービスで WS-Security を使用している場合は、コールバックでメッセージ レベルのセキュリティを使用しないように Web サービスを再設計する必要があります。
|
|
|
|
|
WebLogic Server 9.2 では、Java メソッドの引数または戻り値のパラメータが XmlBean プロパティを含む JAX-RPC 形式の JavaBean である場合、その処理をサポートしていません。たとえば、アプリケーションは次のようなシグネチャのメソッドを持つことはできません。 void myMethod(myJavaBean bean);
public class MyJavaBean {
private String stringProperty;
private XmlObject xmlObjectProperty;
String getStringProperty() {
return stringProperty;
}
void setStringProperty(String s) {
XmlObject getXmlObjectProperty() {
return xmlObjectProperty;
}
void getXmlObjectProperty(XmlObject x) {
|
|
|
|
|
JWSC と clientgen は /tmp ディレクトリの中に schemacom_bea_xml および META-INF という名前の一時ディレクトリを作成しますが、Web サービスの実行後にこれらのディレクトリを削除しませんでした。
|
|
|
|
|
WebLogic Server 9.1 では、RunAs アノテーションで mapToPrincipals 属性を設定する必要があります。次に例を示します。
@RunAs(role="user", mapToPrincipals="foo")
WebLogic Server 9.2 では、 mapToPrincipals 属性は省略可能になり、指定しない場合は、デフォルトのロールに設定されます。既存のアプリケーションは引き続き従来どおりに機能します。
|
|
|
|
|
WebLogic Server で、 JAX-RPC-style 列挙値クラスの java2schema がサポートされていませんでした。
この問題は解決されています。 JAX-RPC-style 列挙値クラスのスキーマ タイプは正しく生成されます。
|
|
|
|
|
ブラウザで Web サービスの基本 URL を指定する場合 (http://localhost:7001/myservice/foo など)、[ WSDL Page] オプションをクリックすると、WSDL ファイルではなく 404 エラーが表示されます。
|
|
|
|
|
WebLogic Server 9.2 は Web サービスの URL で 2 バイト文字の使用をサポートしていません。
WebLogic Workshop 8.1 で作成された Web サービスが URL で 2 バイト文字を使用している場合は、URL から 2 バイト文字をすべて削除するように Web サービスを再設計する必要があります。
|
|
|
|
|
JWS コールバックで 2D XmlObject パラメータを使用すると、 IllegalArgumentException が発生します。
|
|
|
|
|
JAXRPC 仕様に準拠するには、byte[] および Byte[] を xsd:base64Binary 型にマップする必要があります。RPC エンコードの Web サービスで、このマッピングが間違っていました。
この問題は解決されています。RPC エンコードの Web サービスの byte[] および Byte[] は、JAXRPC 仕様に従ってマップされます。「 Ant タスク リファレンス」の jaxRPCWrappedArrayStyle 属性の定義を参照してください。
|
|
|
|
|
@WildcardBinding(className="javax.xml.soap.SOAPElement[]", binding=WildcardParticle.ANYTYPE) のように Web サービス パラメータとして SoapElement[] を使用すると、クライアントでは常に空の配列が生成されます。
SOAPElement[] のデフォルト バインディングを WildcardParticle.ANYTYPE に変更する際に、 @WildcardBinding アノテーションを使用しないようにしてください。 SOAPElement[] のデフォルト バインディングが WildcardParticle.ANY に設定されます。
|
|
|
|
|
双方向 SSL 実装用にサービスごとのキーストアを設定するため、Web サービス クライアント用の API のメカニズムが提供されています。
各接続の証明書を使用して SSL を実装するには、次のように API を使用します。
WlsSSLAdapter adapter = new WlsSSLAdapter();
adapter.setKeystore("./DemoIdentity.jks",
"DemoIdentityKeyStorePassPhrase".toCharArray(), "JKS" );
adapter.setClientCert("DemoIdentity","DemoIdentityPassPhrase".toCharArray());
adapter.setTrustManager( new TrustManager(){
public boolean certificateCallback(X509Certificate[] chain, int
}); weblogic.wsee.connection.transport.https.HttpsTransportInfo info = new
weblogic.wsee.connection.transport.https.HttpsTransportInfo(adapter);
SimpleImplService service = new SimpleImplService_Impl(args[0] +
Simple port = service.getSimpleSoapPort();
stub._setProperty('weblogic.wsee.client.ssladapter', adapter);
|
|
|
|
|
WebLogic Server 9.2 にデプロイされた WebLogic Server 8.1 Web サービスを WebLogic Server 8.1 クライアントから呼び出そうとしても、ソケットの ReadTimout が発生していませんでした。
|
|
|
|
|
型が別のネームスペースに属している場合、WSDL 検証に失敗していました。
|
|
|
|
|
メッセージ ハンドラから SoapFaultException が送出されたときに、EJB は割り当てられていましたがその後解放されていなかったため、EJB リークが発生していました。
|
|
|
|
|
デフォルトではチャンクされない SOAP 応答が、Weblogic Server によって生成されていました。
この問題は解決されています。SOAP 応答のチャンクは無効にできます。
チャンクを無効にすると、応答はメモリ バッファにキャッシュされます。指定されたバッファ サイズを超えると、SOAP メッセージのチャンクが再開されます。
チャンクを無効にするには、WebLogic Server 起動スクリプトで、または WebLogic Server の起動時に weblogic.wsee.NoFlush プロパティを設定します。たとえば -Dweblogic.wsee.NoFlush=true のように設定します。
バッファ サイズを制御するには、コマンドライン パラメータ weblogic.wsee.http.response.BufferSize を、たとえば -Dweblogic.wsee.http.response.BufferSize=<buffer size in Bytes> のように設定します。
なお、バッファ サイズはチャンク サイズの倍数にする必要があるため、実際のバッファ サイズとしてはチャンク サイズの倍数が自動的に割り当てられ、ユーザ指定の値より少し大きい値になります。
|
|
|
|
|
サービスが複数のフロントエンド ホストおよびポートから構成されるクラスタにデプロイされている場合に、動的な WSDL アドレスの場所が誤って生成されていました。
|
|
|
|
|
WebLogic Server Administration Console で、単一の Web サービス オペレーションに複数のポリシー (たとえば sign.xml と auth.xml) を追加することができませんでした。
|
|
|
|
|
WebLogic Server 9.2 で JDK1.5.0_4 を JDK 1.5.0_08 にアップグレードすると、JWSC ANT で問題が発生します。
Windows の場合は setDomainENV.cmd、UNIX の場合は setDomainENV.sh に、-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 を追加します。 ant タスクの実行時には、ANT_OPTS を ANT_OPTS=-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 のように設定します。 ANT ファイル内の Java または Javac タスクのすべてのインスタンスに同じ jvmarg を設定します。次に、build.xml の例を示します。
<java classname="examples.webservices.jws_basic.simple.Client"
<!--Note the jvmarg tag -->
<jvmarg line="-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0" />
<classpath refid="client.class.path"/>
<arg line="http://${wls.hostname}:7001/jws_basic_simple/SimpleService" />
|
|
|
|
|
SOAP 1.2 仕様に準拠するには、SOAP メッセージのコンテンツ タイプを Content-Type: application/soap+xml; charset="utf-8" にする必要があります。これが、Content-Type: text/xml; charset="utf-8" に設定されていました。
この問題は解決されています。コンテンツ タイプは正しく設定されています。
|
|
|
|
|
グローバル JAX-RPC ハンドラが、コーデック ハンドラより前に呼び出されていました。
この問題は解決されています。グローバル JAX-RPC ハンドラは、SOAP メッセージを認識できるよう、Web サービスのコーデック ハンドラの後に呼び出されます。
|
|
|
|
|
クラスタ化された環境でのデータベース永続ストアとの会話において、ストアを論理名で認識することができませんでした。
|
|
|
|
|
無効であるかサポートされていないポリシーが、実行時に検証されません。このため、WebLogic Server にコンフィグレーションされていないユーザが匿名ユーザとしてマップされ、Web サービスは保護されていないものと見なされます。結果として、認可されていないユーザにセキュアな Web サービスへのアクセス権限が付与されてしまいます。
|
|
|
|
|
SAAJ 1.1 の javax.xml.soap.Text.isComment() を使用すると、 UnsupportedOperationException が発生していました。
|
|
|
|
|
PKI 資格マッピングのないユーザが PKI 資格マッピングのあるグループに属している場合、WebLogic Server ではそのユーザ用に PKI 資格を取得できませんでした。
|
|
|
|
|
XMLBean が使用される場合、Web サービスでは elementFormDefault="unqualified" を適用できませんでした。
|
|
|
|
|
document-literal wrapped の規約では、ラップされた配列は有効なラップ要素と見なされませんでした。
サポートが追加され、 allowWrappedArrayForDocLiteral フラグを使用することにより、ラップされた配列がラップ要素として認識されるようになりました。このフラグは clientgen タスクまたは wsdlc Ant タスクについて設定できます。
|
|
|
|
|
Web サービスでは、省略可能な要素 minOccurs="0" を適用できませんでした。リクエスト メッセージ内で省略可能なこの要素を指定して Web サービスを呼び出すと、以下の問題が発生していました。
省略可能なこの要素をリクエスト メッセージから削除すると、Web サービスの呼び出しに失敗する。 Web サービス クライアントが省略可能なこの要素に null 値を指定して Web サービスを呼び出すと、この要素は SOAP 本文に追加され、SOAP 応答の値は空になる。結果の XML で省略可能なこの要素について nillable=false が設定されている場合、この XML はスキーマに対して検証されません。 |
|
|
|
|
ObjectHolder パラメータが特定のスキーマ型に設定されている場合は、 DuplicateElement 例外が発生していました。
サポートが追加され、XMLBean を SOAP ヘッダとして使用できるようになりました。
XMLBean を SOAP ヘッダとして使用する場合は、XMLBean 用のホルダ クラスを作成し、生成済みの xml bean jar ファイルにそのクラスをパッケージ化する必要があります。このホルダは、XMLBean と同じルート パッケージ内、および holders サブパッケージ内に存在する必要があり、名前は <XMLBean Class>Holder になります。ここで、<XMLBean Class> は、ヘッダの IN/OUT パラメータとして渡される XMLBean クラスの名前です。 org.t1M1.tml.tMLTransport.TMLHeaderDocument を保持するには、ホルダ org.t1M1.tml.tMLTransport.holders.TMLHeaderDocumentHolder を使用します。jws ファイルでは、このホルダをヘッダ パラメータに使用します。ホルダ クラスの形式は JAX-RPC ホルダの形式です。
|
|
|
|
|
WebLogic では、次のスキーマ型をサポートしていませんでした。
<s:element ref="s:schema" />
|
|
|
|
|
jwsc Ant タスクでは、1 つの jws ファイル内の複数の転送方式について、ユニークでない serviceUri 要素を検出しておらず、エラーが発生していました。
[jwsc] [ERROR] - 複数のポートの contextPath および
serviceUri "{0}"serviceUri "/stock//StockQuote" が異なっている可能性があります。
|
|
|
|
|
XMLBean 型が別のネームスペースに属している場合、WSDL 検証に失敗していました。
|
|
|
|
|
Web サービスのデプロイメント中に NullPointerException が発生していました。
|
|
|
|
|
SoapFault 処理中にエラーが発生した場合は、例外が発生するのではなく、 null がクライアントに返されていました。
|
|
|
|
|
<xs:include> が XSD で使用される場合は、Web サービスでグローバル型の重複エラーが発生していました。
|
|
|
|
|
jwsc Ant タスクでは、Web サービスのパラメータと結果の多次元配列プロパティを含む JavaBean がサポートされていませんでした。
|
|
|
|
|
添付ファイル付き SOAP メッセージの形式が標準ではありませんでした。SOAP メッセージの Content-Type ヘッダに Type フィールドが含まれていませんでした。
|
|
|
|
|
WebLogic Server クライアントでは、Web サービスからカスタム例外を受け取ると、 SoapCodec.java で NullPointerException が発生していました。
|
|
|
|
|
WebLogic Server 9.2 jwsc で生成される WSDL を WebLogic Server 8.1 で使用する場合は、以下の 2 つの問題が発生していました。
入力パラメータ型および戻り値の型の複雑な型に使用される XML ネームスペースは、最初に xs:import を使用するときにはインポートされませんでした。WebLogic Server 8.1 の clientgen では、これらのネームスペースをインポートする必要がありました。インポートしないと、WebLogic 8.1 の clientgen は失敗しました。 入力パラメータ型および戻り値の型の foo プロパティでは、同じ処理のリクエスト メッセージと応答メッセージの両方で同じ名前のメッセージ部分が作成されます。メッセージ部分が同じ処理のリクエスト メッセージと応答メッセージの両方で同じ名前の場合に、WebLogic Server 8.1 の clientgen は失敗していました。 |
|
|
|
|
Java Bean の配列の引数が Java Web サービスに含まれている場合は、生成される WSDL を Eclipse で検証できませんでした。
|
|
|
|
|
SOAP エラーが RemoteException にラップされる場合は、 ServiceControlexception.hasSoapFault() から true が返されていませんでした。
|
|
|
|
|
Web サービス用に生成された WSDL には、Java クラスの一時的なフィールドが含まれていました。
|
|
|
|
|
参照先のスキーマに "../.." セグメントを含む相対的なインポート/インクルードがある場合、wsdlc から生成される COW ファイルには、インポートされた一部のスキーマが含まれていませんでした。
|
|
|
|
|
インポート/インクルード パスに "/../" を使用して、インポート済みの多数の XSD を含む WSDL から作成された COW ファイルで jwsc を実行すると、インポート/インクルードされるパスが長くなり、パスには多数の ".." セグメントが含まれるため、 FileNotFoundException が発生していました。
|
|
|
|
|
jws インタフェースの webservice メソッドに @WebMethod アノテーションが指定され、jws 実装の同じメソッドに @RolesAllowed アノテーションが指定された場合は、 @RolesAllowed が適用されませんでした。
|
|
|
|
|
WebLogic Server 9.2 の jwsc ant タスクでは、インポートが不足しているため、WebLogic Server 8.1 の clientgen では使用できない WSDL が作成されていました。
|
|
|
|
|
インストールされたサーバ専用キット (プラットフォーム キットではない) と共に UDDI 機能を使用すると、次のエラーが表示され、 UDDIException が発生することがありました。
Error in initializing pluggable tModels.
<WEBLOGIC_HOME>/server/lib/uddi.properties ファイルのエントリ pluggableTModel.file.list をコメントにします。
|
|
|
|
|
wsdl2service タスクによって、webservice.xml 記述子ファイル内にネームスペースの複数のエントリが追加されていました。
|
|
|
|
|
WebLogic Server 8.1 SP5 から WebLogic Server 9.2 MP1 に移行した後に、Web サービス クライアントでエラーが発生していました。
|
|
|
|
|
実行時の SoapResponse デシリアライゼーション中に NullPointerException が発生していました。
|
|
|
|
|
WebLogic Server 9.x で、 SoapFaultException が送出される前に Web サービス クライアントが connect() を複数回呼び出していました。
|
|
|
|
|
プロキシ サービスのエクスポート済み WSDL が、ALSB にインポートされた場合は無効だったことが分かりました。
|
|
|
|
|
JMS WebServiceControl が、JMS 接続を接続プールに返していませんでした。
|
|
|
|
|
WSDL に重複するスキーマ エントリが追加されていたため、デプロイメント中にグローバル タイプの重複に関するエラーが発生していました。
|
|
|
|
|
SOAP メッセージに <Timestamp> ヘッダが追加されるときに <Created> ヘッダと <Expires> ヘッダの両方が存在していないと、Web サービスでエラーが発生していました。
|
|
|
|
|
SAML シグネチャの検証が、証明書解析のエラーで失敗していました。
|
|
|
|
|
XMLBean を使用している場合に、プライマリ スキーマにスキーマが含まれており、含まれているスキーマ内の型が参照されていると、jwsc Ant タスクが無効な WSDL を生成していました。jwsc タスクによって各スキーマのスキーマ セクションが生成され、含まれているスキーマ内の型がプライマリ スキーマから解決されていませんでした。
|
|
|
|
|
1 次元の SOAP 配列および可変長を使用する Web サービスが正しく処理されていませんでした。空の配列を処理する際に、Web サービスでエラーが発生していました。
|
|
|
|
|
大きな XMLBean jar ファイル内の型を参照すると、ServiceControl アセンブリのパフォーマンスが低下していました。
この問題は解決されています。 -Dweblogic.wsee.bind.useExistingXBeans というシステム プロパティが導入されました。デフォルト値は false です。このプロパティを true に設定すると、参照された XMLBean がすでにクラスパスに存在する場合はコンパイルが実行されません。
|
|
|
|
|
Web サービスが WebLogic Workshop から実行された場合、生成された SOAP メッセージの解析中の特定の状況において、elementFormDefault='unqualified' の XSD を使用して作成された Workshop サービス コントロールでエラーが発生していました。
|
|
|
|
|
<xs:extension> 要素を含むスキーマ型用に、間違った Java マッピングが生成されていました。
|
|
|
|
|
デフォルトの文字セットを使用する JMS を介して Web サービスを呼び出すと IOException が発生していました。
|
|
|
|
|
weblogic.wsee.workarea.WorkAreaClientHandler クラスで、 handleRequest() メソッドが常にログ メッセージを出力していました。
この問題は解決されています。verbose はデフォルトでは無効になりました。
|
|
|
|
|
要素に maxOccurs='unbounded' が指定されていると、生成されたサービス コントロールに XMLBean 型の間違ったシグネチャが含まれていました。
|
|
|
|
|
JMS 転送を使用して JMS ByteMessage を複数回送信すると例外が発生していました。
|
|
|
|
|
WebLogic Server が、以下の点で WSRM 標準に準拠しませんでした。
WSRM 仕様では、順番に送信されてくる一連のメッセージ全体に対して 1 回のみ確認応答を送信することになっているが、WebLogic Server ではメッセージを受信するたびに確認応答メッセージが送信されていた。 WebLogic Server では、最後の空のメッセージに対して確認応答を送信していなかった。 |
|
|
|
|
ポリシーが適用された Web サービス メソッドを呼び出す場合に、そのメソッドで WorkContext API を使用して Web サービス呼び出し間のデータを伝播していると、Web サービスでヘッダ重複エラーが発生していました。
|
|
|
|
|
SAML アサーションを使用してメッセージに署名している場合、シグネチャの検証で NullPointerException が発生していました。
|
|
|
|
|
クライアント接続の作成時に、 SOAPConnectionImpl クラスでハードコード化された SOAP11 バインディング タイプが使用されていました。
この問題は解決されています。SOAP メッセージでは、SOAP11 または SOAP12 が動的に使用されます。
|
|
|
|
|
EJB ベースの SOAP 1.2 JAXRPC サービスの認証に失敗したときに生成される SOAP エラーに、間違ったコンテンツ タイプが含まれていました。
|
|
|
|
|
JWS のパラメータに多次元配列が含まれていると、JWS のコンパイルに失敗していました。
|
|
|
|
|
WSDL で xsd:anyType と xsd:restrictions を同時に使用すると、 xsd:anyType バインディングの処理中にコンテナから NullPointerException が送出されていました。
|
|
|
|
|
wsdlc Ant タスクを使用して WSDL から Web サービス実装をビルドすると、生成された JWS に base64Binary または hexBinary の間違ったホルダ クラスが含まれていました。
|
|
|
|
|
共通のグローバル要素名を使用するスキーマが別のネームスペースにあっても、XBean を使用して作成した Web サービスではそのスキーマを処理することができませんでした。
|
|
|
