ADBException: sous-élément Inattendu

J'ai créé un service web à l'aide de:

Apache Axis 2 CodeGen Assistant v. 1.6.2 (Reliure: ADB)
Eclipse Juno
Tomcat 7
Java 6

Le Service retourne une Coutume Objet Java (DataBean) pour le client, mais je suis tombé sur une exception dans le code de client:

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

De ce que j'ai fait des recherches, sur n une fois de plus ... je pense que c'est un problème très commun, mais n'ont pas encore obtenu une réponse définitive quant à ce qui devrait être fait pour y remédier.

Quelques posts sur ce sujet et sur d'autres forums de l'état que le WSDL doit être modifié (nom de l'espace), ou le stub client a besoin d'être modifié. Certains ont même état qu'il y a un bug au sein de la BAD. C'était sûrement un bug dans les versions antérieures de l'Axe, mais il y a un grand nombre de postes dans le courrier-archives indiquant que le bug a été corrigé. Ceux de diffusion des archives ont été liés à des versions antérieures de Axis2.

Maintenant mes questions sont:

Est-il encore un bug ?
Exactement ce qui doit être changé dans le fichier WSDL ou le stub Client ?

Ce qui est intéressant de mentionner est que j'ai créé un semblable service web qui renvoie à une "Chaîne" de retour vers le client. Il fonctionne très bien ! Donc, il échoue lorsqu'un type de données complexe est impliqué.

Il y avait quelques informations sur Le site web de Apache, sous la rubrique "Limitations Connues"...

Il lit: "BAD est destiné à être un "Simple" cadre de la liaison de données et ne visait pas à compiler tous les types de schémas. Les limitations suivantes sont les plus mis en évidence.

De Type complexe Extensions et Restrictions."

Est le problème ?

Ce qui suit est l'extrait de code à partir du fichier WSDL qui pourrait être de quelque intérêt pour vous...

<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 ? Dois-je inclure quelques autres fragments de code ici?

OriginalL'auteur Mandeep Singh | 2013-05-15

11

"Inattendu sous-élément" signifie que le message reçu par le récepteur contient un élément XML que le récepteur ne m'y attendais pas. "{schemaTargetNs}message" est le nom de l'élément inattendu, qu'il rencontrait. En d'autres termes, l'expéditeur a envoyé un message non valide pour le récepteur.
- L'expéditeur peut avoir inclus un élément dont il n'était pas censé le faire.
- L'expéditeur peut avoir laissé de côté un élément obligatoire.
- L'expéditeur a peut-être mettre les éléments dans le bon ordre.
- L'expéditeur peut avoir envoyé un complètement message incorrect.
Si le serveur émis l'exception que vous avez signalé, alors le client a envoyé un message non valide pour le serveur. Si le client a émis l'exception, alors que l'erreur est dans la réponse du serveur au client.

L'erreur est certainement dans la réponse du serveur, mais comment savoir quel élément a été prévu ? Sauf si je sais que je ne serai pas en mesure de réparer les choses. J'ai la réponse XML du serveur et il semble bien pour moi.
Eh bien, si vous exécutez le client dans un débogueur, et/ou si vous avez eu la stacktrace pour le org.apache.axis2.AxisFault, alors vous pourriez trouver la ligne de code spécifique dans le message analyseur qui est en train de jeter la faute. Il devrait être évident à ce point de quel élément il s'attendait.
C'est probablement à la baisse sur le fait que le client a été généré à partir d'une copie incorrecte du fichier WSDL. Donc, la réponse envoyée par le serveur ne correspond pas à ce que le client attend.
Oui, j'ai pu voir de quoi il s'attendait, mais ne savait pas si ce qu'il attend a droite c'est à dire si le code est correct. Probablement confondu par le fait que de nombreuses personnes ont posté sur les listes de discussion en indiquant que c'était effectivement un problème avec l'Axe. Et c'est ce qui s'est avéré être...
Le code généré par CodeGen (à partir de WSDL) de l'Objet Java (haricot) que j'ai été en utilisant, prévu un espace de noms différent dans les champs de haricots. J'ai corrigé ça et sa fonctionne bien. Encore perplexes quant à la manière incorrecte wsdl / code a été généré par Axe CodeGen?

OriginalL'auteur Kenster
6

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

A fonctionné pour moi aussi!

OriginalL'auteur Gorson
1

Regarder dans votre .fichier xsd. Trier vos xs éléments par ordre alphabétique ci-dessous votre <xs:extension base=...>. Adaptée à vos besoins.

OriginalL'auteur StarCrafter
1

Le code généré par CodeGen (à partir de WSDL) de l'Objet Java (haricot) que j'ai été en utilisant, prévu un espace de noms différent dans les champs de haricots. En quelque sorte un espace de noms incorrect était présent dans le code généré par l'Axe. Je fixe l'espace de noms de réfléchir à ce qu'il avait été et tout a bien fonctionné. Je peux voir des gens encore à répondre à cette question, de sorte pensé que je re-poste ma solution ici (déjà posté cette question dans sa réponse à Kenster de la solution). Comme aucune des solutions posté avant moi de trouver la solution a fonctionné, je n'ai pas accepter toute réponse.

OriginalL'auteur Mandeep Singh
0

Quand j'ai vérifié l'axe de code, j'ai trouvé le suivant
```
if( new javax.xml.namespace.QName("http://someurl","someElementName").equals(reader.getName()) )
```
c'est où l'erreur se produit,
. méthode equals() de QName vérifie localPart & namespaceURI
. mais lecteur.getName() n'a pas d'espace de noms URI définie et donc l'erreur de se passer

J'ai changé tous les si-vérification de
```
if( new javax.xml.namespace.QName("http://someurl","someElementName").equals(reader.getName()) )
```
à
```
if( new javax.xml.namespace.QName("someElementName").equals(reader.getName()) )
```
et il a bien fonctionné pour moi

OriginalL'auteur deenfirdoush
0

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

OriginalL'auteur Klendatho
0

dans mon cas, le Service Web est l'envoi d'éléments dans un ordre différent de la séquence sur le xsd. Je suis modifiant le talon droit maintenant si l'ordre n'a pas d'importance, parce que je n'ai aucune chance de modifier le Service Web.

OriginalL'auteur Julián Sosa
0

J'ai eu le même problème. Lorsque le base64binary surmonté 16k limite de l'analyseur commence à donner de l'erreur, de façon Substantielle, il s'arrête de lire le contenu après 16k alors, évidemment, le reste du document semble corrompu.

Mon problème est que j'ai été à l'aide de com.soleil.xml.flux de données.XMLReaderImpl.

Retrait
```
<dependency>
<groupId>com.sun.xml.stream</groupId>
<artifactId>sjsxp</artifactId>
</dependency>
```
et l'ajout de
```
<dependency>
<groupId>org.codehaus.woodstox</groupId>
<artifactId>wstx-asl</artifactId>
</dependency>
```
résolu mon problème (wstx comme suggéré précédemment a été de travail)

OriginalL'auteur Stefano Ghezzi

Vous devez vous connecter pour publier un commentaire.