# JAX-WS - Klassengenerierung durch wsimport



## JayGabriel (6. Sep 2011)

Hallo,

ich habe ein bestehendes WSDL File mit einem dazu gehörenden Schema-XML File, aus denen ich mit Hilfe von 
	
	
	
	





```
wsimport
```
 meine Types und Service Klassen generieren lasse. Soweit klappt alles wunderbar und ohne weitere Fehler.

Wenn ich nun aber Änderungen an der Schema-XML oder an dem WSDL-File vornehme, hab ich bisher jedoch das Problem, dass alle zuvor schon generierten Klassen immer wieder mit überschrieben werden. Wenn ich genau an den Klassen etwas ändere, ist es wohl ein Übel mit dem ich leben muss. Doch gibt es auch eine Möglichkeit, alte und nicht angetastete Klassen zu behalten, während die neu Hinzugekommenen generiert werden?

mfg
Jay


----------



## mvitz (6. Sep 2011)

Die Frage ist doch, wieso änderst du an diesen Klassen etwas?

Soweit ich weiß, sollten diese NICHT geändert werden.


----------



## JayGabriel (7. Sep 2011)

Ganz einfach, da ich den WebService als Bindeglied zwischen einem seperaten Operations-Backend und einem schon aufgesetzten WebFrontend bauen soll und dort bestimmte Definitionen erwartet werden.
So musste ich je zwei Konstruktoren noch hinzufügen und natürlich den Dokumentationsteil austauschen.

Wenn du mir sagst, wie ich den Definitionen in der Schema-XML je zwei Konstruktoren hinzufüge, wär ich auch schon zufrieden  JavaDoc wird zwar dann noch immer überschrieben, aber nach Fertigstellung, müsste ich das alles ja eh noch einmal überarbeiten.

mfg
Jay


----------



## TheDarkRose (7. Sep 2011)

Die Klassen einfach nicht bearbeiten. Lieber davon erben oder in einer anderen kapseln.


----------



## JayGabriel (7. Sep 2011)

???:L Öhm, was soll denn diese Antwort...?

Wie schon geschrieben... es werden zwei wichtige Konstruktoren erwartet, das kann ich schlecht ignorieren, denn dann würde meine Schnittstelle nicht funktionieren.

Und nach dem Ändern funktioniert ja alles wunderbar.

Der Hinweis, dass nichts geändert werden _sollte_, ist bei mir angekommen, daher ja auch meine Frage, wie ich im Schema die zwei verschiedenen Konstruktoren anlegen kann. Doch ich befürchte, dass das nicht möglich ist, da ja Code darin enthalten sein muss. Und mit Vererbung arbeite ich so wenig wie möglich, wenn es sich vermeiden lässt...

mfg
Jay


----------



## mvitz (7. Sep 2011)

Habe gerade nochmal kurz gegoogled und bin auf folgendes gestoßen: java - need to use custom classes instead of generated (by wsimport) in web-services - Stack Overflow

Wie es also aussieht nutzt JAX-WS JAXB und für JAXB gibt es die Möglichkeit über JAXB-Bindings das Standard Verhalten zu ändern (zumindest Dokumentation könnte damit funktionieren). Ob man damit auch neue Konstruktoren hinzufügen kann, weiß ich gerade leider nicht.

Da ich mich zuletzt mit JAXB-Bindings auseinandergesetzt habe, hier ein paar Links, die dir hoffentlich helfen:

http://java.sun.com/xml/ns/jaxb/bindingschema_2_0.xsd
Reference of Schema (JAXB binding customization)
Customizing JAXB Bindings
Customizing JAXB Bindings


----------



## JayGabriel (7. Sep 2011)

Vielen Dank für die Links  Werd mich gleich mal darin vertiefen.

mfg
Jay


----------



## mvitz (7. Sep 2011)

Ansonsten könntest du dir die Konstruktoren noch dynamisch hinzufügen per

Byte Code Enhancement
AOP (z.B. AspectJ)

oder (ich weiß nicht genau wie stark sich dein Schema ändert) versuchen, das ganze über patch und ein patchfile zu machen.


----------



## Gelöschtes Mitglied 5909 (7. Sep 2011)

ich verstehe den zusammenhang zwischen konstruktoren und schnittstelle nicht. 

was ist denn bitte an einem konstruktor eine schnittstelle?

wenn es darum geht die objekte zu füllen, wieso benutzt du nicht die generierten setter?


----------



## ARadauer (7. Sep 2011)

Ohne mir jetzt genauere Gedanken gemacht zu haben... Adapter Pattern?
Eine Schnittstelle erwartet was, was meine Klasse nicht erfüllt und ich solls nicht ändern? Eine Klasse machen die die Schnittstelle erfühlt und meine Klasse beinhaltet...


----------



## JayGabriel (8. Sep 2011)

Es werden Konstruktoren benötigt, da beim "Neuerstellen" eines Objektes zwingend notwendige Attribute schon gesetzt sein müssen. Und da es bisher mit überladenen Konstruktoren gelöst worden war, wollte ich dabei bleiben. Es gab schon einen minimalen WebService, der mit Axis 1 erstellt worden ist und nun soll ich den mit JAX-WS nachbauen und erweitern. Ich hatte ja gehofft, dass ich durch das Zusammenklicken des Schemas und des WSDLs mir das ganze Klassenändern sparen könnte und mit 
	
	
	
	





```
wsimport
```
 dann einfach die Klassen generieren kann. Dass dabei Konstruktoren untern Tisch fallen, konnte ich ja nicht ahnen.

Im Sinne einer Schnittstelle: vielleicht hab ich mich da etwas blöd ausgedrückt, aber mit meinen Klassen werden auch andere arbeiten müssen (á la "ich geb sie dir und du musst nix mehr dran ändern"). Ich mache also die Vorarbeit und definiere alle benötigten Typen (UND Konstruktoren) und Standardwerte und verbinde später auch die "Datenverwaltung" über den WebService mit dem "WebFrontend".

Das Adapter Pattern war mir auch schon eingefallen, finds nur etwas umständlich nur weil ich zwei verschiedene Konstruktoren brauche.

Nach dem langen hin und her gestern, werd ich wohl auf das 
	
	
	
	





```
wsgen
```
 zurückgreifen und das "Klicken" sein lassen müssen. Wär nur praktisch gewesen, weil damit Änderungen am Code von Hand direkt nicht notwendig gewesen wären (hätte es eine Möglichkeit zum Konstukorengenerieren gegeben).

Danke jedenfalls für die viele Hilfe 

mfg
Jay


----------



## Gelöschtes Mitglied 5909 (9. Sep 2011)

sollten die zwingend erforderlichen typen nicht in der schnittstelle definiert sein?
Und die Schnittstelle ist in dem fall die WSDL, deren Datentypen wiederum man aus einem XML Schema generieren kann.

Und in einem XML Schema kann man die typen auf required setzen. 
Über Konstruktoren das ganze zu machen halte ich für äußerst Fragwürdig. 
Was passiert wenn jemand nicht deine "Library" verwendet, sondern sich die Klassen selbst generiert?


----------



## JayGabriel (9. Sep 2011)

Hmm, ich fürchte, du hast mich missverstanden?

Ich habe doch die Typen über das Schema generiert!? Und auf Required habe ich auch die zwingend Notwendigen gesetzt. Aber man kann doch nicht angeben mit "welchen" Werten diese Variablen schließlich vorinitialisiert werden müssen.

Zumindest habe ich keine Möglichkeit dafür gefunden und dahin zielte zum Anderen auch meine Anfrage.

Bisher wurde das Vorinitialisieren (nicht Deklarieren) über die Konstruktoren gelöst und die werden ja nun durch die Klassengenerierung aus dem Schema nicht mehr mitgeneriert. Daher meine Frage, ob es eine Möglichkeit gibt Konstruktoren (am besten mit explizitem Inhalt) ebenfalls generieren zu lassen. Und falls nicht, bin ich auch weiterhin gern für andere Vorschläge offen.

mfg
Jay


----------



## JayGabriel (12. Sep 2011)

So, ich hab mich nun noch ein wenig weiter damit beschäftigt, aber bin meinem eigentlichen Ziel noch immer nicht viel näher gekommen.

Wenn ich nun mit "WSGEN" arbeite, kann ich zwar alles mögliche in meine WebServiceImpl Klasse schreiben, dort wirds auch benutzt, aber wenn ich nun den Client generiere, sind alle Initialisierungen weg, als ob ich sie nicht geschrieben hätte...

Abhilfe schafft, wenn ich die Typ-Klassen, die ich im WebService von Hand geschrieben hab, in meinen WebServiceClient hinüber kopiere. Aber das kann doch auch nicht der Sinn der ganzen Sache sein, oder? Dann könnt ich auch weiter mit dem "WSIMPORT" arbeiten, da würde ich mir das ganze Getippe sparen.

Meine einzige Umgehung, die zumindest erst einmal ans Ziel führt, ist nun, dass ich mit die Defaultwerte und -objekte einfach auch über den WebService hole. Dort sind ja nun alle entsprechenden Werte durch das von Hand ausprogrammieren gesetzt. So lasse ich mir ein vollständiges "DefaultClient"-Objekt übergeben, in dem schon alle wichtigen Werte gesetzt sind. Besser geht das dann noch, wenn man das Objekt nur ein Mal läd und dann vorrätig hält, um den WebService nicht ständig zu belasten. Aber das Gelbe vom ist es noch immer nicht.

mfg
Jay


----------

