CXF-Serviceaufruf fehlgeschlagen mit Unmarshalling-Fehler auf unerwartetem Namespace

Question

Ich stolpere auf ein Problem mit CXF (2.7.18) plötzlich. Ich laufe unter Tomcat 8.0.28 und JDK 1.8.0_66.

Das Problem ist, dass wir vor kurzem Probleme sahen, wo es Serviceaufrufe mit entsprechenden Headern nicht akzeptieren würde. Der Haken ist, dass es auf einigen Systemen funktioniert, aber nicht auf anderen.

Das Scheitern präsentiert sich wie folgt:

Unmarshalling Error: unexpected element (uri:"http://www.namedomain.com", local:"loginRequest"). Expected elements are <{https://www.namedomain.com}loginRequest> 

Bitte beachten Sie, dass das unerwartete Element das richtig Namespace-Element ist. Die "Expected" -Elemente sind falsch - CXF oder etwas anderes in der Pipeline ordnet den Namespace-URI neu an "https" an

Irgendwelche Hinweise darauf, was das verursacht und wie man es korrigiert?

Answer 1

Ich konnte das Problem feststellen. Dies ist eine Kuriosität, die bei unseren vorherigen Tests nie aufgetaucht ist.

Hier ist die allgemeine Zusammenfassung. Die betreffende Anwendung, die diese WSDL verwendet, generiert die Bindung aus der Definition und speichert sie im Paket 'com.foo'.

Die Anwendung ist auch von einem anderen WSDL-Endpunkt abhängig, aber dieses Modul wurde separat erstellt, hatte jedoch einen kollidierenden Paketnamen 'com.foo'.

In unseren früheren Tests ist dies nie aufgetaucht.

Irgendwann, während der Migration zu Java 8 & Tomcat 8, tauchte dieses Problem zeitweise auf bestimmten Feldern auf, aber nicht auf anderen. Etwas an dem VM-Bild, das wir verwenden, beeinflusst die Ladereihenfolge. Das heißt nicht, dass wir von der Ladereihenfolge abhängig sind, aber wir haben die Kollision nie gesehen.

Sowohl die externe Bibliothek als auch die Anwendungsbibliothek hatten ein package-info.java mit widersprüchlichen Namespacedefinitionen für die XmlSchema-Annotation. Die Ladereihenfolge wurde unter Java 8/Tomcat 8 "geändert", wodurch die Kollision offensichtlich wurde. Die erste geladene Paket-Information wird zwischengespeichert und verursacht den Fehler.

Die Lösung besteht darin, die Generierung des WSDL-Bindungscodes durch die Anwendung zu ändern, um sie in ein anderes Paket zu integrieren und die Kollision zu vermeiden.