Bij een poging om een web service proxy te genereren met behulp van de 'cxf-codegen-plugin' treed bij ons de een fout op die aangeeft het attribuut 'attributeFormDefault' tegen te zijn gekomen op een plek waar dit niet hoort.
Om te zien wat er aan de hand is heb ik vervolgens de WSDL geopend en vanuit de editor (Intelij) een validate uitgevoerd. Deze laat vervolgens de volgende 2 fouten zien:
cvc-complex-type.3.2.2: Attribute 'elementFormDefault' is not allowed to appear in element 'definitions'.
cvc-complex-type.3.2.2: Attribute 'attributeFormDefault' is not allowed to appear in element 'definitions'.
Om uit te sluiten dat dit een issue is met de ontwikkelomgeving heb ik nog geprobeerd om de WSDL in te lezen SoapUI (5.2.0) maar ook hier krijg ik een foutmelding op het attribuut 'attributeFormDefault':
WSDLException (at /definitions): faultCode=INVALID_WSDL: Encountered illegal extension attribute 'attributeFormDefault'. Extension attributes must be in a namespace other than WSDL's.
Het blijkt dat de betreffende attributen binnen alle 5 de WSDL's in de ztc0310 folder zijn opgevoerd.
Ik heb tenslotte nog even kort met Visual Studio getest en deze lijkt bovenstaande attributen te negeren, omdat onze services werken op basis van Java is ook dit geen optie.
Ik heb naar aanleiding hiervan een tweetal vragen:
- Is bovenstaande een probleem van de door ons gebruikte tools, of kloppen de WSDL's inderdaad niet helemaal? Zijn er tools die worden aanbevolen voor het valideren van de WSDL's
- Is er iemand die op basis van JAVA de WSDL's van de ZTC heeft kunnen inlezen (zonder deze eerst handmatig aan te passen)?
Met vriendelijke groet,
Patrick
Patrick,
Bedankt voor je melding. Ik ga deze discussie na het plaatsen van deze post verplaatsen naar het forum voor StUF-ZTC aangezien hij daar, gezien het onderwerp, ook thuis hoort.
Toch alvast een antwoord: het StUF-ZTC sectormodel is het eerste sectormodel dat wij deels hebben gegenereerd en daarbij zijn de attributes 'elementFormDefault' en 'attributeFormDefault' automatisch overgenomen uit het schema dat de basis vormt voor alle schema's en WSDL's in dit sectormodel. Deze horen er echter inderdaad niet in thuis.
Er moeten dus 2 dingen gebeuren:
XML-Spy staat het gebruik van deze attributes net als Visual Studio gewoon toe. Oxygen dat werkt op basis van Xerxes niet.
KING beveelt overigens geen tools aan. Wellicht kunnen je collega's in het veld je wel wat aanbevelingen doen.
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0410.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Hallo Robert,
We hebben hier inmiddels met de hand de foutieve XML attributen verwijdert, om te kijken of het inlezen van de WSDL's daarna wel lukt. Echter liepen we ook hierna nog tegen een fout aan.
Bij het inlezen van de WSDL werd telkens een melding gegeven dat de definities voor o.a. Bv01Bericht, Fo01Bericht en diverse andere types afkomstig uit de stuf0301.xsd dubbel aanwezig waren binnen de WSDL's. Deze melding werd wederom vanuit diverse op JAVA gebaseerde tools gegeven en niet vanuit .NET. Na enig zoekwerk hebben we de oorzaak voor de melding kunnen vinden. Bij een aantal namespace includes werd er een afwijkende casing gebruikt voor de import van de stuf0301.xsd file. Omdat JAVA erg strikt is voor wat betreft de casing ziet de software afwijkende casing ook als een andere waarde. Bij het verwerken van de WSDL en XSD bestanden wordt iedere afwijkende casing dan ook gezien als een ander bestand en dus apart ingelezen. Op de meeste plekken staat "stuf0301.xsd" conform de filenaam op schijf, echter binnen de navolgende bestanden staat "StUF0301.xsd":
Is het binnen de door jullie gebruikte generatiesoftware mogelijk om de gebruikte casing voor de namespace imports gelijk te houden waar het fysiek om dezelfde file gaat?
Hoi Patrick,
Bedankt voor je input. In dit geval ligt de oorzaak niet in de generatiesoftware maar in het schema dat door de generatiesoftware wordt gebruikt als bron bestand. Op basis van dat bestand worden dus alle schema's en wsdl's gegenereerd. Op sommige plaatsen is de verwijzing naar 'stuf0301.xsd' echter hard in het generatiescript opgenomen vandaar de verschillen.
We zullen dat bron bestand dus aan passen en ons voortaan goed moeten realiseren dat er codegeneratie-software is die daar gevoelig voor is (is dit trouwens niet in te stellen?). Ik zal dit daarom als waarschuwing opnemen in de handleiding.
Zijn er trouwens Operating Systems waarin het bestand stuf0301.xsd naast het bestand STUF0301.xsd kan bestaan?
Want als dat niet het geval is dan vraag ik me af waarom de codegeneratie-software daar wel gevoelig voor is.
Hallo Robert,
In de eerste plaats wederom bedankt voor de snelle reactie.
Voor wat betreft de eerste vraag is het voor zover ik weet niet mogelijk om op een generieke manier case insensitive te werken vanuit de CXF component. Zoals gezegd is JAVA erg strikt in de case toepassing. Indien er een specifiek commando wordt uitgevoerd binnen JAVA dan is het soms wel mogelijk om de case verschillen expliciet te negeren, echter is er zover ik weet vanuit CXF geen optie om op binnen deze tool gebruikte JAVA aangeroepen op te geven dat dit Case insensitive moet gebeuren.
Om een antwoord op jou tweede vraag te geven is het zo dat op UNIX / Linux systemen deze bestanden inderdaad naast elkaar kunnen bestaan.
Aangezien XML zelf ook case-sensitive is zou ik ervoor willen pleiten om ook bij de generatie tool case-sensitive te werken. Dus stuf0301.xsd is dan wel degelijk een ander bestand dan StUF0301.xsd.
Hoogstwaarschijnlijk is het feit dat XML Spy en Visual Studio dit toestaan gebaseerd op dat deze tools beide op windows draaien. De StUF standaarden zijn echter niet OS-specifiek en zouden op alle platforms moeten draaien.
In de bijgaande zip file zijn in de wsdl bestanden van het sectormodel ztc0310 de attributes 'elementFormDefault' en 'attributeFormDefault' verwijderd.
Daarnaast is in de bestanden:
de waarde van het 'schemaLocation' attribute van het eerste 'import' element gewijzigd van '../../0301/StUF0301.xsd' in '../../0301/stuf0301.xsd'.
Bijlage
Tijdens de StUF Expertgroep van 17 februari 2016 is het voorstel goedgekeurd.
Het onderhoudsverzoek is omgezet naar een erratum (ERR0410).