私は以下を使用してWebサービスを作成しました:
サービスはカスタムJavaオブジェクト(DataBean))をクライアントに返しますが、クライアントコードで例外に遭遇しました。
org.Apache.axis2.AxisFault: org.Apache.axis2.databinding.ADBException: Unexpected subelement {schemaTargetNs}message
私が調査したことから、何度も繰り返します...これは非常に一般的な問題だと思いますが、それを修正するために何をすべきかについての決定的な答えはまだありません。
このフォーラムや他のフォーラムのいくつかの投稿では、WSDLを変更する必要がある(一部の名前空間)か、クライアントスタブを変更する必要があると述べています。 ADBにバグがあると言う人もいます。それは確かに以前のバージョンのAxisのバグでしたが、バグが修正されたことを示す多くの投稿がメールアーカイブにあります。それらのメーリングアーカイブは、Axis2の以前のバージョンに関連していました。
今私の質問は:
言及する価値があるのは、クライアントに「文字列」を返す同様のWebサービスを作成したことです。うまくいきます!したがって、複雑なデータ型が関係している場合は失敗します。
ApacheのWebサイト の「Known Limitations」という見出しの下にいくつかの情報がありました...
「ADBは「シンプルな」データバインディングフレームワークであり、すべてのタイプのスキーマをコンパイルすることを意図したものではありません。次の制限が最も強調されています。
それは問題ですか?
以下は、WSDLファイルからのスニペットです。これは、あなたにとって興味深いかもしれません...
<wsdl:types>
<xs:schema xmlns:ax26="http://mywebservice/xsd" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="schemaTargetNs">
<xs:import namespace="http://mywebservice/xsd"/>
<xs:element name="getMsg">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="reqData" nillable="true" type="ax25:DataBean"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="getMsgResponse">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="return" nillable="true" type="ax25:DataBean"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://mywebservice/xsd">
<xs:complexType name="DataBean">
<xs:sequence>
<xs:element minOccurs="0" name="message" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="name" nillable="true" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</wsdl:types>
どうすれば問題を解決できますか?ここに他のコードスニペットを含める必要がありますか?
CodeGenが(WSDLから)生成したJavaオブジェクト(bean)のオブジェクト(bean)のコード)は、Beanのフィールドに異なる名前空間を予期していました。コードに誤った名前空間が存在していましたAxisによって生成されました。名前空間を修正して、本来あるべき状態を反映し、すべてが正常に機能しました。人々がこの質問にまだ答えているのを見ることができるので、ここに私のソリューションを再投稿します(ケンスターのソリューションへの応答としてこれをすでに投稿しています)。解決策を見つける前に投稿した解決策はどれも機能しなかったため、私は回答を受け入れませんでした。
「予期しないサブ要素」とは、受信者が受信したメッセージに、受信者が予期していないXML要素が含まれていたことを意味します。 「{schemaTargetNs} message」は、遭遇した予期しない要素の名前です。つまり、送信者は無効なメッセージを受信者に送信しました。
サーバーが報告した例外を発行した場合、クライアントはサーバーに無効なメッセージを送信しました。クライアントが例外を発行した場合、エラーはサーバーからクライアントへの応答にありました。
xsd(wsdl)がxmlリクエストで正しい場合応答は、問題はxml要素の順序にあるためです。 1つの可能な解決策は、-Eosvオプションを使用してaxis2クライアントを生成することです。それは私のために働きます。
.xsdファイルを調べます。 <xs:extension base=...>
の下でxs要素をアルファベット順に並べ替えます。それはあなたのニーズに合います。
私の場合、Webサービスは、xsdにあるシーケンスとは異なる順序で要素を送信しています。今はスタブを変更しているので、Webサービスを変更する機会がないので、順序は関係ありません。
このエラーは、誤解を招く可能性があります。 WSDLを変更して新しい必須要素を追加した後、クライアントを作成しました。このエラーが表示されたより。解決策は、この要素をWebサービスの1つのメソッドに入力するのを忘れていたことです。このエラーが表示された場合は、必須要素がサーバー内に入力されているかどうかも確認してください。
軸コードを確認したところ、次のことがわかりました
if( new javax.xml.namespace.QName("http://someurl","someElementName").equals(reader.getName()) )
ここでエラーが発生します。 QNameのequals()メソッドは、localPartとnamespaceURIをチェックします。しかし、reader.getName()には名前空間URIが設定されていないため、エラーが発生しました
すべてのif-checkを
if( new javax.xml.namespace.QName("http://someurl","someElementName").equals(reader.getName()) )
に
if( new javax.xml.namespace.QName("someElementName").equals(reader.getName()) )
そしてそれは私にとってはうまくいった
私も同じ問題を抱えていました。 base64binaryが16kの制限を克服すると、パーサーがエラーを出し始めます。実質的には、16kの後でコンテンツの読み取りを停止するため、明らかにドキュメントの残りの部分が破損しているようです。
私の問題は、com.Sun.xml.stream.XMLReaderImplを使用していたことでした。
削除しています
<dependency>
<groupId>com.Sun.xml.stream</groupId>
<artifactId>sjsxp</artifactId>
</dependency>
そして追加
<dependency>
<groupId>org.codehaus.woodstox</groupId>
<artifactId>wstx-asl</artifactId>
</dependency>
私の問題を解決しました(以前に提案されたwstxが機能していたため)