I am using below wsdl2java plugin configured to generate java classes using WSDL.
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>3.0.1</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<sourceRoot>${basedir}/src/main/java</sourceRoot>
<wsdlOptions>
<wsdlOption>
<wsdl>src/main/resources/XXXXService.wsdl</wsdl>
<validate>none</validate>
<extraargs>
<extraarg>-server</extraarg>
<extraarg>-impl</extraarg>
<extraarg>-verbose</extraarg>
<extraarg>-p</extraarg>
<extraarg>http://XXX/YY=XXX</extraarg>
<extraarg>-autoNameResolution</extraarg>
</extraargs>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
Now, I have below schema included in my WSDL.
<xsd:include schemaLocation="myschema.xsd" xmlns="tns"></xsd:include>
When my element definition is within my WSDL like below, it generates a class for myElement , which is fine:
<xsd:element name="myElement">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="a" type="xsd:string"
minOccurs="1">
</xsd:element>
<xsd:element name="b" type="xsd:string"
minOccurs="1">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
But when my element definition in WSDL refers to a ComplexType definition in schema. Then the element class aaa doesn't get generated only aaaType class gets generated.
<xsd:element name="aaa"
type="tns:aaaType">
</xsd:element>
Is there a way I can specify wsdl2java to generate both classes aaa and aaaType and reference aaaType inside aaa ?
You can check xmlns:tns and targetNamespace on both WSDL and the schema.
<xsd:element name="aaa"... - it can be defined in schema itself.
You can try to browse the WSDL and check if it is proper, as issue seems to be related to schema include.
Related
I have schema defined in Request.xsd which will refer common.xsd.
I'm expecting the output should come as below
<Request xmlns="http://ws.myref.com/schemas/test"
xmlns="http://ps.myref.com/schemas/2008/Common">
<EmailList>
<Mail>test#gmail.com</Mmail>
</EmailList>
</Request>
But i'm getting extra namespace "ns2" issue. Can anybody help me out to resolve this issue
<ns2:Request xmlns:ns2="http://ps.myref.com/schemas/test"
xmlns="http://ps.myref.com/schemas/Common">
<ns2:EmailList>
<Mail>test#gmail.com</Mail>
</ns2:EmailList>
</ns2:Request>
Request.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" targetNamespace="http://ps.myref.com/schemas/schemas/test"
xmlns="http://ps.myref.com/schemas/schemas/test" xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
xmlns:com="http://ps.myref.com/schemas/Common">
<xsd:import namespace="http://ps.myref.com/schemas/Common" schemaLocation="../schemas/common/common.xsd"/>
<xsd:element name="Request">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="EmailLists" type="com:EmailList" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Common.xsd
<?xml version="1.0"?>
<xsd:schema xmlns="http://ps.myref.com/schemas/2008/Common" elementFormDefault="unqualified"
targetNamespace="http://ps.myref.com/schemas/Common"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<xsd:complexType name="EmailList">
<xsd:sequence>
<xsd:element name="Mail" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
Your expectation is unreasonable in this instance.
Because the type "EmailList" is defined under the namespace http://ps.myref.com/schemas/2008/Common in the common.xsd file, you have no option but to differentiate it in some way when you use the EmailList type in another schema. If you look at request.xsd, you can see that this is exectyly what happens here:
<xsd:element name="EmailLists" type="com:EmailList" />
The com: in this case is a prefix designed to show that the type is defined in another schema and under a different namespace to the one being used.
In the same way, when the xsd validator uses the request.xsd to validate a schema instance, it has to ensure that the EmailList type you are using in your instance is the same EmailList type which is defined in the common.xsd schema, and the only way it can do that is by using the namespace.
Your expectation can therefore be summarized thus:
"I should be able to mix types defined in two different schema definitions freely together without differentiating them and the parser should understand that."
So you should be able to see now how your expectation does not make logical sense.
If you don't want the "ns2:" in there, your only other alternative is to do this:
<Request xmlns"http://ps.myref.com/schemas/test">
<EmailList xmlns"http://ps.myref.com/schemas/test">
<Mail xmlns="http://ps.myref.com/schemas/Common">test#gmail.com</Mail>
</EmailList>
</Request>
I have a xml string which is a response from third party server.
<?xml version="1.0" encoding="utf-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<GetRateQuoteResponse>
<GetRateQuoteResult>
</GetRateQuoteResult>
</GetRateQuoteResponse>
</SOAP-ENV:Body></SOAP-ENV:Envelope>
I want to parse it in JAX-WS.
So i converted this String to xsd file using this web site
The web site gave me the xsd as follows.
<?xml version="1.0" encoding="utf-16"?>
<xsd:schema attributeFormDefault="unqualified" elementFormDefault="qualified" version="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="SOAP-ENV:Envelope">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="SOAP-ENV:Body">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="GetRateQuoteResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="GetRateQuoteResult" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
I now generate JaxB classes from this xsd, it tries to create class named
SOAP-ENV:Envelope and SOAP-ENV:Body which is invalid name for a class and it fails to do so.
Also even if i modify xsd to Envelope and Body the Unmarshalling fails.
javax.xml.bind.UnmarshalException: unexpected element (uri:"http://schemas.xmlsoap.org/soap/envelope/", local:"Envelope"). Expected elements are <{}SOAP-ENV:Envelope>
Please guide.
The XSD should not contain any SOAP elements; only the WSDL does. The XSD by definition is or data only. The transport protocol information (SOAP) should not be in the data definition as XSDs have applications outside of SOAP.
Omit the SOAP schema elements from the entry you pass to the XSD generato. By including that stuff in there, you're indicating to the generator that those elements will be part of your JAXB-generated classes (which shouldn't be the case). What you should feed the generator is the excerpt below, which would rightly generate the GetRateQuoteResponse-containing schema
<GetRateQuoteResponse>
<GetRateQuoteResult>
</GetRateQuoteResult>
</GetRateQuoteResponse>
The result:
<?xml version="1.0" encoding="utf-16"?>
<xsd:schema attributeFormDefault="unqualified" elementFormDefault="qualified" version="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="GetRateQuoteResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="GetRateQuoteResult" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
I am working with an xsd, trying to get it to validate an xml.
The xml is used to create objects. There are two types of objects that can be created by the elements in the list: SC and SMSC. SMSC is an SC, and extends it.
SMSC doesn't contain any new properties. From the perspective of the xml, an SMSC is identical to an SC in every way, except that the elements that define its properties are wrapped by <SMSC> tags instead of <SC> tags.
Our XSD looks like this:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name='Definitions'>
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="unbounded" name="SC">
<!--SNIP properties of SC and SMSC -->
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Is there a way to change this to allow either SC or SMSC as the element, other than duplicating all of the property definitions in an SMSC element? We don't want to have to double the length of the document and duplicate all of the property definitions.
As it stands, the only validation error we have in our XML is where we have an SMSC element. If there isn't a way to fix this without duplicating all the property definitions we'll leave it as-is, but we'd obviously prefer to eliminate the warning this throws if practical.
While it is confusing by tags instead of tags, I would think that below is either answering your question, or elicits better explanations.
So, what you see is avoiding duplication; you don't actually need the additional type SMSC (see Definitions2), but I've put it just in case (Definitions). Making the SMSC element of the SC type would work exactly the same.
The difference between Definitions / Definitions2 and Definitions3 is that one uses substitution groups instead of choices. I personally prefer substitution groups to choices, yet is not that uncommon to run into issues related to substution groups (i.e. they are poorly supported here and there).
<?xml version="1.0" encoding="utf-8" ?>
<!-- XML Schema generated by QTAssistant/XSD Module (http://www.paschidev.com) -->
<xsd:schema targetNamespace="http://tempuri.org/XMLSchema.xsd" xmlns="http://tempuri.org/XMLSchema.xsd" elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:complexType name="SC">
<xsd:sequence>
<!-- Stuff goes here -->
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="SMSC">
<xsd:complexContent>
<xsd:extension base="SC"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="Definitions">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<xsd:element name="SC" type="SC"/>
<xsd:element name="SMSC" type="SMSC"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<!-- Another way -->
<xsd:element name="Definitions2">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<xsd:element name="SC" type="SC"/>
<xsd:element name="SMSC" type="SC"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="Definitions3">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="SC" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SC" type="SC" />
<xsd:element name="SMSC" type="SMSC" substitutionGroup="SC" />
</xsd:schema>
The following schema should be generating two primitive int fields in a Value class, but instead generates a primitive int for the element and java.lang.Integer for the attribute.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema version="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.com/test" xmlns:test="http://www.example.com/test"
elementFormDefault="qualified">
<xsd:element name="values">
<xsd:complexType>
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="test:value" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="value">
<xsd:complexType>
<xsd:sequence>
<!-- Is generated as primitive int -->
<xsd:element name="element" type="xsd:int" />
</xsd:sequence>
<!-- Is generated as java.lang.Integer -->
<xsd:attribute name="attribute" type="xsd:int" />
</xsd:complexType>
</xsd:element>
</xsd:schema>
I've looked through the JAXB documentation for anything that says that attributes and elements may be generated differently and found nothing.
Can anyone explain this? Is there a fix to make the attribute generate as a primitive int?
I'm not entirely sure this is the answer, but I had an epiphany while debugging my app.
The default multiplicity for an element in an XML schema is 1..1 (required) where as the default multiplicity for an attribute is 0..1 (optional).
So, since the element is required and a primitive in Java has a default value (most likely 0), it makes sense to generate an <xsd:element type="xsd:int" /> as a Java primitive.
Since the attribute is optional there is a possibility that it may be nillable which would not be possible using a primitive. The java.lang.Integer is an Object and thus allowed to be null, so it makes sense to generate an <xsd:attribute type="xsd:int" /> as an java.lang.Integer.
If you make an attribute be required (<xsd:attribute type="xsd:int" use="required" />), it will generate as a primitive int. I haven't seen documentation by JAXB that explicitly says this, but that doesn't mean it doesn't exist; perhaps I just missed it.
For this xml:
<elem1 xmlns="http://www.fixprotocol.org/ns/fast/t/1.0">
<elem2>
<elem2/>
</elem2>
</elem1>
I have this schema, which seems to validate fine against w3 schema validation service, and the schema validates the above XML just fine. Sadly, xsd.exe and some other tools report it to be an error. Is that correct? Are circular group refs dissallowed by XML schema? Thanks!
Update: The schema is not mine, can't change it :(
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.fixprotocol.org/ns/fast/t/1.0" xmlns:t="http://www.fixprotocol.org/ns/fast/t/1.0">
<xs:element name="elem1">
<xs:complexType>
<xs:group ref="t:grp1" />
</xs:complexType>
</xs:element>
<xs:group name="grp1">
<xs:sequence>
<xs:group ref="t:grp2" />
</xs:sequence>
</xs:group>
<xs:group name="grp2">
<xs:sequence>
<xs:element minOccurs="0" name="elem2">
<xs:complexType>
<xs:group ref="t:grp1" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:group>
</xs:schema>
It's a legal scheme. Problem is that xsd is trying to traverse all dependencies. The MS version preprocesses scheme and expands all groups. Because of the cyclic dependency such expansion would be infinite so it quits with an error. With the Mono version there are two probable scenarios:
It tries to traverse dependency tree
and ends up in an infinite loop.
It tries to expand all groups and
ends up in an infinite loop.
That is just my guess. I never saw actual source codes of Mono xsd.
This question is being linked with many recent questions that talk about the same problem: circular groups, and Microsoft's xsd.exe, hence I think it should be answered, even though it is quite "old".
The confusion is caused by what qualifies as a circular group. According to section 3.8.6 of the XSD spec:
"Circular groups are disallowed. That is, within the {particles} of a
group there must not be at any depth a particle whose {term} is the
group itself."
Based on the above, your example is not a circular group, since the group itself does not rely on itself as a particle. Your schema is valid.
This is a circular group:
<?xml version="1.0" encoding="utf-8"?>
<xsd:schema xmlns="http://www.fixprotocol.org/ns/fast/t/1.0" attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.fixprotocol.org/ns/fast/t/1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="elem1">
<xsd:complexType>
<xsd:group ref="grp1"/>
</xsd:complexType>
</xsd:element>
<xsd:group name="grp1">
<xsd:sequence>
<xsd:choice>
<xsd:group ref="grp1"/>
</xsd:choice>
</xsd:sequence>
</xsd:group>
</xsd:schema>
One cannot rewrite a true circular group. However, your example can be rewritten in a couple of ways: the schema below shows an equivalent content model, based on recursive complex types.
<?xml version="1.0" encoding="utf-8" ?>
<!-- XML Schema generated by QTAssistant/XSD Module (http://www.paschidev.com) -->
<xsd:schema xmlns="http://www.fixprotocol.org/ns/fast/t/1.0" attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.fixprotocol.org/ns/fast/t/1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation xmlns="">Generated from "Set1" under "Release2"</xsd:documentation>
</xsd:annotation>
<xsd:complexType name="grp1">
<xsd:sequence>
<xsd:element minOccurs="0" name="elem2" type="grp1"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="elem1" type="grp1"/>
</xsd:schema>
It is also "entertaining" to see that the following schema actually works with xsd.exe:
<?xml version="1.0" encoding="utf-8"?>
<!--XML Schema generated by QTAssistant/XML Schema Refactoring (XSR) Module (http://www.paschidev.com)-->
<xsd:schema xmlns="http://www.fixprotocol.org/ns/fast/t/1.0" attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.fixprotocol.org/ns/fast/t/1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation xmlns="">Generated from "Set1" under "Release2"</xsd:documentation>
</xsd:annotation>
<xsd:element name="elem1">
<xsd:complexType>
<xsd:group ref="grp1"/>
</xsd:complexType>
</xsd:element>
<xsd:group name="grp1">
<xsd:sequence>
<xsd:element minOccurs="0" name="elem2">
<xsd:complexType>
<xsd:group ref="grp1"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:group>
</xsd:schema>
From an XML instance perspective, all three valid schemas are equivalent.
The issue is probably that the tools you are using don't support all possibilities supported by the XML schema spec. Certainly xsd.exe doesn't support everything. The spec is gigantic and it isn't worth providing mappings from everything it supports into a programming language, particularly when some things just don't map very well.
To work around this, you could try to create a set of C# classes that mimic the xml you want to generate and then run xsd.exe on those classes to generate an xsd. There is probably some other XML schema construct that supports what you want.
I don't know about groups but XSD.exe supports circular elements:
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Class1" nillable="true" type="Class1" />
<xs:complexType name="Class1">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="1" name="Name" type="xs:string" />
<xs:element minOccurs="0" maxOccurs="1" name="child" type="Class1" />
</xs:sequence>
</xs:complexType>
</xs:schema>