Unmarshalling Fehler: unerwartetes element von legacy-Anfrage mit legacy-WSDL
Ich erhalte eine SOAP-Anfrage aus, dass einige legacy-code, und der Umgang mit Hilfe von JAX-WS generierten Objekte aus der gleichen WSDL-legacy-code verwendet, aber ich bin immer ein Unmarshalling Fehler: unerwartetes element Fehler, wenn ich die Anforderung nicht verarbeiten.
WSDL-Teil für diese Anforderung ist wie folgt: (Bitte beachten Sie "schema" wurde abgelöst von dem eigentlichen schema-locations für unsere WSDL)
<xsd:complexType name="Administrate">
<xsd:sequence>
<xsd:element name="AdminOperation" type="typens:AdminOperation" maxOccurs="unbounded" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="Administrate" type="typens:Administrate"/>
<xsd:complexType name="AdministrateResponse">
<xsd:sequence>
<xsd:element name="Status" type="typens:SoapResponseStatus"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="AdministrateResponse" type="typens:AdministrateResponse"/>
<xsd:complexType name="AdminOperation">
<xsd:sequence>
<xsd:choice>
<xsd:element name="Transaction" type="typens:Transaction" minOccurs="0"/>
<xsd:element name="CreateUser" type="typens:CreateUser" minOccurs="0"/>
<xsd:element name="DeleteUser" type="typens:DeleteUser" minOccurs="0"/>
<xsd:element name="UpdateUser" type="typens:UpdateUser" minOccurs="0"/>
<xsd:element name="CreateGroup" type="typens:CreateGroup" minOccurs="0"/>
<xsd:element name="DeleteGroup" type="typens:DeleteGroup" minOccurs="0"/>
<xsd:element name="UpdateGroup" type="typens:UpdateGroup" minOccurs="0"/>
<xsd:element name="CreateChannel" type="typens:CreateChannel" minOccurs="0"/>
<xsd:element name="DeleteChannel" type="typens:DeleteChannel" minOccurs="0"/>
<xsd:element name="UpdateChannel" type="typens:UpdateChannel" minOccurs="0"/>
<xsd:element name="CreateRole" type="typens:CreateRole" minOccurs="0"/>
<xsd:element name="DeleteRole" type="typens:DeleteRole" minOccurs="0"/>
<xsd:element name="UpdateRole" type="typens:UpdateRole" minOccurs="0"/>
<xsd:element name="CreateFileType" type="typens:CreateFileType" minOccurs="0"/>
<xsd:element name="DeleteFileType" type="typens:DeleteFileType" minOccurs="0"/>
<xsd:element name="UpdateFileType" type="typens:UpdateFileType" minOccurs="0"/>
<xsd:element name="CreateFolder" type="typens:CreateFolder" minOccurs="0"/>
<xsd:element name="DeleteFile" type="typens:DeleteFile" minOccurs="0"/>
<xsd:element name="MoveFile" type="typens:MoveFile" minOccurs="0"/>
<xsd:element name="CopyFile" type="typens:CopyFile" minOccurs="0"/>
<xsd:element name="UpdateFile" type="typens:UpdateFile" minOccurs="0"/>
<xsd:element name="DeleteJob" type="typens:DeleteJob" minOccurs="0"/>
<xsd:element name="DeleteJobNotices" type="typens:DeleteJobNotices" minOccurs="0"/>
<xsd:element name="UpdateJobSchedule" type="typens:UpdateJobSchedule" minOccurs="0"/>
<xsd:element name="UpdateVolumeProperties" type="typens:UpdateVolumeProperties" minOccurs="0"/>
<xsd:element name="UpdateOpenSecurityCache" type="typens:UpdateOpenSecurityCache" minOccurs="0"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
und die Anfrage gesendet:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" xmlns="schema">
<SOAP-ENV:Header>
<AuthId>7</AuthId>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<Administrate>
<UpdateFile>
<SetPermissions>
<Permission SOAP-ENC:arrayType="Permission[1]">
<UserName>username</UserName>
<AccessRight>rights</AccessRight>
</Permission>
</SetPermissions>
<NameList>
<String>folder1</String>
<String>folder1/folder2</String>
<String>folder1/folder2/file.ext</String>
</NameList>
</UpdateFile>
</Administrate>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Aber ich bekomme den folgenden Fehler aus meinem code:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Client</faultcode>
<faultstring>Unmarshalling Error: unexpected element
(uri:"schema", local:"UpdateFile"). Expected elements
are <{schema}AdminOperation> </faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Die Administration von JAX-WS generierten Objekt enthält eine ArrayList von AdminOperations mit einem getter,
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "Administrate", propOrder = {
"adminOperation"
})
public class Administrate {
@XmlElement(name = "AdminOperation")
protected List<AdminOperation> adminOperation;
/**
* Gets the value of the adminOperation property.
*
* <p>
* This accessor method returns a reference to the live list,
* not a snapshot. Therefore any modification you make to the
* returned list will be present inside the JAXB object.
* This is why there is not a <CODE>set</CODE> method for the adminOperation property.
*
* <p>
* For example, to add a new item, do as follows:
* <pre>
* getAdminOperation().add(newItem);
* </pre>
*
*
* <p>
* Objects of the following type(s) are allowed in the list
* {@link AdminOperation }
*
*
*/
public List<AdminOperation> getAdminOperation() {
if (adminOperation == null) {
adminOperation = new ArrayList<AdminOperation>();
}
return this.adminOperation;
}
}
Aber die Beurteilung von der alten auf die Anfrage gesendet und von der WSDL-dieser Vorgang-tag ersetzt wird, mit der Wahl von Operationen, z.B. updatefile etc richtig?
Als ich nicht ändern kann der Erbe verlangen oder legacy-WSDL, ich bin mir nicht sicher, wie es weitergehen soll. Jede Hilfe wäre sehr geschätzt, danke im Voraus!
InformationsquelleAutor m0rv4i | 2012-07-19
Du musst angemeldet sein, um einen Kommentar abzugeben.
Sich Ihr Verdacht richtig ist. In diesem Fall ist der Kunde tatsächlich sendet eine Anforderung, die nicht im Einklang mit den vorgesehenen schema.
Da hast du keine Kontrolle über den client-code und scheinbar muss Platz für die Kunden, meine Hoffnung ist, dass es der einzige client für diesen Dienst. Der einfachste Weg vorwärts wäre Sie zum anpassen der service-Vertrag-der Kunde wurde tatsächlich gebaut. Könnte man manuell anpassen des Schemas, zu zeigen, dass UpdateFile ist ein Kind der Verwaltung, dann regen die relevanten Objekte oder (nicht die Mühe mit dem regen von Objekten) optimieren die Verwalten java Objekt Annotationen zu reflektieren FileUpdate als erste Ebene Kind:
...
@XmlType(name = "Verwalten", propOrder = {
"updateFile"
})
public class Administrieren {
...
Due diligence wäre, erkennen auch die anderen Formen der Anfrage (führen Sie dem Vertrag entsprechen) um sicherzustellen, dass kein weiterer Bruch bei der Anpassung der service-Endpunkt.
Sie haben die richtige Idee mit den Elementen und der Pfad zu 'UpdateFile'. Ich weiß nicht, alle Ihre constratins, aber ich würde die Notierung der generierten Klasse eine Zeit, dann legt es in eine Struktur, wo es würde nicht mehr überschrieben werden, da das, was Sie nach ist eine Klasse, die eigentlich nicht im Einklang mit der mitgelieferten schema sowieso. Eine weitere Möglichkeit (je nach Komfort) könnte es sein, betreiben Sie auf die xml-Rohdaten (aus dem message context) auf und wandeln es in Einklang mit dem schema (dann würde erfordern explizite unmarshalling in ein Objekt).
Ok vielen Dank für die Hilfe, wir haben einige CXF Abfangjäger bereits vorhanden und aufgrund der Einschränkungen möglicherweise nur das xml Bearbeiten. Nochmals vielen Dank.
InformationsquelleAutor dcbyers