2012-07-11 8 views
5

JAX-WS erfordert, dass alle Klassen, die übertragen werden, einen Standardkonstruktor haben (kein Arg-Konstruktor). Ich verstehe diese Anforderung nicht, da Clients ihre eigenen Klassen basierend auf der WSDL erstellen. IMO Diese Anforderung ist nur für die Klassen sinnvoll, die als Eingabeparameter des Webservice verwendet werden.Warum ist ein Standardkonstruktor für Objekte erforderlich, die von einem JAX-WS exportiert werden?

Kann jemand diese Anforderung umgehen?

Antwort

6

Wenn Sie JAX-WS Sie verwenden eine JAXB Implementierung der Java-Objekte XML serialisiert werden.

Also, das 'Problem' ist, wie JAXB funktioniert.

JAXB verwenden, müssen Sie ein JAXBContext Leiten alle Klassen erstellen, die/unmarshal gemarshallt werden kann. Beim Erstellen des Kontexts prüft JAXB, ob alle angegebenen Klassen einen Konstruktor ohne Argumente haben. Wenn mindestens eine dieser Klassen nicht über diese Art von Konstruktor verfügt, wird der Kontext nicht erstellt.

Warum JAXB dies tun? Er benötigt diesen no-arg-Konstruktor NUR bei der Umwandlung von XML in Object (Unmarshalling), aber das Problem ist, wenn Sie den Kontext erstellen, JAXB weiß nicht, was Sie tun wollen (Marshal oder Unmarshal)!

Fazit: JAXB akzeptiert nur Klassen, die es marshalieren UND unmarshalen kann. Weitere Informationen here

Wissen, was passiert in JAX-WS?

Wenn Sie deklarieren einen @WebMethod die Parameter und Rückgabewert Klassen werden zu einem JAXB Kontext hinzugefügt werden. Aus diesem Grund benötigen alle Klassen, die sich auf die Eingabe und Ausgabe eines Webdienstes beziehen, einen Konstruktor ohne Argumente.

Fazit: ist JAXB Fehler ;-)

Aber was, wenn ich brauche eine Klasse zu verwenden, die keine nicht-arg Konstruktor hat?

Sie können einen XMLAdapter verwenden! Überprüfen Sie this post für weitere Informationen ...

+0

So scheint das Problem zu sein, dass JAXB nicht zwischen Klassen unterscheidet, die es Marshalling oder Unmarshale hat. Wenn diese Funktion unterstützt wurde, konnte JAX-WS einen entsprechenden JAXBContext erstellen. Ich denke, das würde eine nette Feature-Anforderung für eine kommende JAXB-Spezifikation machen. – Stefan

+0

Ich stimme Ihnen voll und ganz zu. Tatsächlich haben die Leute von MOXy (eine JAXB-Implementierung von EclipseLink) ein offenes Ticket, um Unterstützung für Konstruktoren mit mehreren Argumenten hinzuzufügen: https://bugs.eclipse.org/bugs/show_bug.cgi?id=328951 – ggarciao

0

Kann jemand diese Anforderung umgehen?

Ja - JAX-WS neu schreiben.

Es ist wahrscheinlich mit einem Standard-Ctor und Reflexion, um Objekte zu füllen, weil es nicht leicht über jeden möglichen ctor wissen kann, dass jemand wie Sie schreiben könnte.

Dies ist ein Nachteil der Verwendung eines fremden Frameworks: Sie müssen nach ihren Regeln spielen.

Kunden ihre eigenen Klassen auf der Basis der WSDL

Ich dachte, das ist, was die Bibliothek half Kunden tun. Sie haben den Code nicht geschrieben, um die WSDL zu analysieren und zu interpretieren, oder?

+0

Die Objekte dürfen nicht von JAX-WS auf der Serverseite aufgefüllt werden. JAX-WS überträgt sie nur. – Stefan