web-dev-qa-db-fra.com

ADBException: sous-élément inattendu

J'ai créé un service Web en utilisant:

  • Apache Axis 2 CodeGen Wizard v.1.6.2 (Liaison: ADB)
  • Eclipse Juno 
  • Tomcat 7
  • Java 6

Le service renvoie un objet Java personnalisé (DataBean) au client, mais je suis tombé sur une exception dans le code client:

org.Apache.axis2.AxisFault: org.Apache.axis2.databinding.ADBException: Unexpected subelement {schemaTargetNs}message

D'après mes recherches, encore et encore ... Je pense que c'est un problème très courant, mais je n'ai pas encore de réponse concluante quant à la marche à suivre pour le corriger. 

Certaines publications sur ce forum et d'autres indiquent que le WSDL doit être modifié (un espace nom), ou que le stub client doit être modifié. Certains déclarent même qu'il y a un bug dans la BAD. C’était sûrement un bogue dans les versions précédentes d’Axis, mais il existe de nombreuses publications dans les archives de courrier qui indiquent que le bogue a été corrigé. Ces archives de mailing étaient liées à des versions antérieures d'Axis2. 

Maintenant mes questions sont:

  1. Est-ce toujours un bug?
  2. Que faut-il exactement changer dans le WSDL ou le stub client?

Il est à noter que j'ai créé un service Web similaire qui renvoie une "chaîne" au client. Ça fonctionne bien ! Donc, cela échoue lorsqu'un type de données complexe est impliqué.

Il y avait quelques informations sur le site Web d'Apache , sous la rubrique " Limitations connues " ...

Il se lit comme suit: " ADB est censé être un cadre de liaison de données 'simple' et ne vise pas à compiler tous les types de schémas. Les limitations suivantes sont les plus soulignées .

  1. Extensions et restrictions de types complexes . "

Est-ce le problème? 

Ce qui suit est l'extrait du fichier WSDL qui pourrait vous intéresser ...

<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>

Maintenant, comment puis-je résoudre le problème? Devrais-je inclure d'autres extraits de code ici? 

web-servicesexceptionaxis2
10
Mandeep Singh

Le code généré par CodeGen (à partir de WSDL) pour l’objet Java (bean) que j’utilisais attendait un espace de noms différent pour les champs du bean. D'une manière ou d'une autre, un espace de nom incorrect était présent dans le code généré par Axis. J'ai corrigé l'espace de noms pour refléter ce qu'il aurait dû être et tout a bien fonctionné. Je peux voir des gens qui répondent encore à cette question, alors j'ai pensé poster à nouveau ma solution ici (je l'ai déjà posté en réponse à la solution de Kenster). Comme aucune des solutions postées avant de trouver la solution ne fonctionnait, je n’ai accepté aucune réponse.

1
Mandeep Singh

"Sous-élément inattendu" signifie que le message reçu par le destinataire contient un élément XML que le destinataire ne s'attendait pas. "{schemaTargetNs} message" est le nom de l'élément inattendu rencontré. En d'autres termes, l'expéditeur a envoyé un message non valide au destinataire.

  • L'expéditeur peut avoir inclus un élément qui n'était pas censé l'être.
  • L'expéditeur peut avoir omis un élément obligatoire.
  • L'expéditeur peut avoir placé les éléments dans le mauvais ordre.
  • L'expéditeur peut avoir envoyé un message complètement incorrect.

Si le serveur a émis l'exception que vous avez signalée, le client a envoyé un message non valide au serveur. Si le client a émis l'exception, alors l'erreur était dans la réponse du serveur au client.

11
Kenster

si le xsd (wsdl) est correct avec la demande xml, la réponse est parce que le problème est l'ordre des éléments xml. Une solution possible consiste à générer votre client axis2 avec l'option -Eosv. ça marche pour moi.

6
Gorson

Regardez dans votre fichier .xsd. Triez vos éléments xs par ordre alphabétique sous votre <xs:extension base=...>. Cela conviendra à vos besoins.

1
StarCrafter

dans mon cas, le service Web envoie des éléments dans un ordre différent de celui de la séquence figurant sur le xsd. Je modifie le stub en ce moment, l'ordre n'a donc pas d'importance, car je n'ai aucune chance de modifier le service Web.

0
Julián Sosa

Cette erreur peut être un peu trompeuse. Après avoir modifié le WSDL et ajouté un nouvel élément obligatoire, j'ai créé mon client. Que cette erreur est apparue. La solution a été que j'ai oublié de remplir cet élément avec l'une des méthodes de mon service Web. Si cette erreur apparaît, vérifiez également si vos éléments obligatoires sont renseignés sur le serveur.

0
Klendatho

Quand j'ai vérifié le code de l'axe, j'ai trouvé ce qui suit

if( new javax.xml.namespace.QName("http://someurl","someElementName").equals(reader.getName()) )

c'est là que l'erreur se produit, . La méthode equals () de QName recherche LocalPart & namespaceURI . mais reader.getName () n'a pas d'URI d'espace de nom défini, d'où l'erreur

J'ai changé tous les if-check de

if( new javax.xml.namespace.QName("http://someurl","someElementName").equals(reader.getName()) )

à

if( new javax.xml.namespace.QName("someElementName").equals(reader.getName()) )

et cela a bien fonctionné pour moi

0
deenfirdoush

J'ai eu le même problème. Lorsque la base64binary a dépassé la limite de 16k, l'analyseur commence à donner l'erreur, mais il arrête substantiellement de lire le contenu après 16k. Il est donc évident que le reste du document semble corrompu.

Mon problème était que j'utilisais com.Sun.xml.stream.XMLReaderImpl. 

Enlever

<dependency>
<groupId>com.Sun.xml.stream</groupId>
<artifactId>sjsxp</artifactId>
</dependency>

et en ajoutant

<dependency>
<groupId>org.codehaus.woodstox</groupId>
<artifactId>wstx-asl</artifactId>
</dependency>

résolu mon problème (donc wstx comme suggéré avant fonctionnait)

0
Stefano Ghezzi