Closed SaNuelson closed 2 years ago
Ten problém bude způsoben právě tím, že jste si argumenty přejmenoval na jména bez targetNamespace (nekvalifikovaná).
Generované schéma nemá nastaveno elementFormDefault
kde default je unqualified
, tedy nehledě na targetNamespace
definované elementy nejsou kvalifikované. Vaše schéma má "qualified"
, a tedy elementy patří do namespace.
Tedy když si je pojmenováváte, zřejmě bude třeba také nastavit ten target namespace, viz třeba: https://stackoverflow.com/questions/16915962/how-can-i-configure-the-target-namespace-globally-in-jax-ws-web-services, nebo ze schématu vyhodit tu kvalifikovanou formu.
Ďakujem za pomoc.
Vyriešil som to nakoniec zmazaním elementFormDefault="qualified"
z WSDL.
Pridaním targetNamespace
do @WebService
sa mi to nepodarilo úplne vyriešiť.
Presnejšie sa tento namespace nepropagoval do @WebParam
a podobne, kde ho bolo treba dodefinovať explicitne pre každý parameter a return value....
Pri ďalšom hľadaní problému som napr. narazil na: https://stackoverflow.com/questions/5793352/jax-ws-why-nested-elements-are-in-namespace
kde sa odpoveď odkazuje na už neaktuálnu stránku ws-i.org, ktorý tvrdí, že je to proper behaviour, a síce že namespace sa používa iba na vonkajší element a vnútorné elementy sú bez ak sa nemýlim.
Ak by to nebolo v poriadku, prosím, dajte vedieť, skúsim sa na to ešte pozrieť. No v momentálnej podobe je to, ak sa nemýlim, plne funkčné.
Ručne písané WSDL vygeneruje:
Na čo príde response:
V prípade WSDL auto-generovaného webserverom je to:
a response je vtedy v poriadku:
Očividne teda zavadzia namespace pri
<jobType>
, no nie som si istý ako sa ho zbaviť, a či vôbec je to správne riešenie. Pred týmto som menil samotný Java interface, kde som pridal@WebParam
atribúty do interfaceov, aby som sa vyhol SOAPu obsahujúcemu<arg0>...
. Nie som si teda istý, či to nespôsobuje to.Po vŕtaní sa vo generovanom WSDL mi nie je jasné, prečo tam ten namespace chýba, keďže XSD tam používa ten istý namespace:
versus moje: