So I was going to attempt to work around this problem by defining my
complexType, rather than using an anonymous complexType. I've run
across another issue, possibly another bug. When I define the
complexType outside of the element and reference the type like so:
<xsd:element name="GetWeatherByZipCode"
type="tns:GetWeatherByZipCodeBody" />
<xsd:complexType name="GetWeatherByZipCodeBody">
<xsd:choice>
<xsd:sequence>
<xsd:element minOccurs="0" maxOccurs="1"
name="ZipCode"
type="xsd:string" />
</xsd:sequence>
<xsd:sequence>
<xsd:element minOccurs="0" maxOccurs="1"
name="ZipCodeTest" type="xsd:string" />
</xsd:sequence>
</xsd:choice>
</xsd:complexType>
...Alter the code so that it references the new type (did not change the
WebParam name or anything, merely referenced the new type) like so:
@WebMethod
@WebResult(name="GetWeatherByZipCodeResponse")
GetWeatherByZipCodeResponse
GetWeatherByZipCode(@WebParam(name="GetWeatherByZipCode")
GetWeatherByZipCodeBody body, MessageContext context);
When the WSDL is generated, it creates a 2nd GetWeatherByZipCode element
in my schema (after it uses the schema I provide), like so (snippet):
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:tns="http://www.webservicex.net"; elementFormDefault="qualified"
targetNamespace="http://www.webservicex.net";>
<xsd:element name="GetWeatherByZipCode"
type="tns:GetWeatherByZipCodeBody"/>
<xsd:complexType name="GetWeatherByZipCodeBody">
<xsd:choice>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0"
name="ZipCode" type="xsd:string"/>
</xsd:sequence>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0"
name="ZipCodeTest" type="xsd:string"/>
</xsd:sequence>
</xsd:choice>
</xsd:complexType>
<xsd:element name="GetWeatherByZipCodeResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1"
name="GetWeatherByZipCodeResult" type="tns:WeatherForecastsType"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="WeatherForecastsType">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1"
name="Latitude" type="xsd:float"/>
<xsd:element maxOccurs="1" minOccurs="1"
name="Longitude" type="xsd:float"/>
<xsd:element maxOccurs="1" minOccurs="1"
name="AllocationFactor" type="xsd:float"/>
<xsd:element maxOccurs="1" minOccurs="0"
name="FipsCode" type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0"
name="PlaceName" type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0"
name="StateCode" type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0" name="Status"
type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0" name="Details"
type="tns:ArrayOfWeatherData"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ArrayOfWeatherData">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0"
name="WeatherData" type="tns:WeatherData"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="WeatherData">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" name="Day"
type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0"
name="WeatherImage" type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0"
name="MaxTemperatureF" type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0"
name="MinTemperatureF" type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0"
name="MaxTemperatureC" type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0"
name="MinTemperatureC" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="GetWeatherByZipCode" type="tns:GetWeatherByZipCodeBody"/>
</xsd:schema>
Notice the last <xsd:element />, it's the same as the one I've defined
at the top of the schema however this 2nd one is generated and inserted
by the WSDL generation code. Why is WSDL generation creating a 2nd
element?
Any thoughts?
Thanks!
Eric Miles
On Thu, 2006-12-28 at 08:17 -1000, Dan Diephouse wrote:
> This looks like a bug. Could you please file a JIRA issue for it? If
> you could attach your WSDL which shows the breakage that'd be much
> appreciated as well.
>
> Regards,
>
> - Dan
>
> On 12/28/06, Eric Miles <[EMAIL PROTECTED]> wrote:
> >
> > When I have an anonymous complexType defined on a Jaxb2 service elemnt with
> > an xsd:choice indicator, the WsGen task generates clients without
> > parameters. For example, if I take the WeatherService example provided in
> > the distribution and run WsGen on it, the resulting interface has the
> > appropriate in parameters on the web method. Below are the relevant code
> > snippets:
> >
> > xsd:
> > <xsd:element name="GetWeatherByZipCode">
> > <xsd:complexType>
> > <xsd:sequence>
> > <xsd:element minOccurs="0" maxOccurs="1" name="ZipCode"
> > type="xsd:string"/>
> > </xsd:sequence>
> > </xsd:complexType>
> > </xsd:element>
> >
> > generated interface:
> > @WebMethod(operationName = "GetWeatherByZipCode", action = "")
> > @WebResult(name = "GetWeatherByZipCodeResult", targetNamespace =
> > "http://www.webservicex.net";)
> > public WeatherForecastsType getWeatherByZipCode(
> > @WebParam(name = "ZipCode", targetNamespace =
> > "http://www.webservicex.net";)
> > String ZipCode);
> >
> >
> > However, if I add an xsd:choice to the above XSD for the
> > GetWeatherByZipCode element and run WsGen, I get NO parameters for the
> > resulting web method. See below for relevant code snippets:
> >
> > xsd:
> > <xsd:element name="GetWeatherByZipCode">
> > <xsd:complexType>
> > <xsd:choice>
> > <xsd:sequence>
> > <xsd:element minOccurs="0" maxOccurs="1" name="ZipCode"
> > type="xsd:string"/>
> > </xsd:sequence>
> > <xsd:sequence>
> > <xsd:element minOccurs="0" maxOccurs="1" name="TestZipCode"
> > type="xsd:string"/>
> > </xsd:sequence>
> > </xsd:choice>
> > </xsd:complexType>
> > </xsd:element>
> >
> > generated interface:
> > @WebMethod(operationName = "GetWeatherByZipCode", action = "")
> > @WebResult(name = "GetWeatherByZipCodeResult", targetNamespace =
> > "http://www.webservicex.net";)
> > public WeatherForecastsType getWeatherByZipCode();
> >
> > Is this a bug with WsGen with an anonymous complexType? I believe I tried
> > this with an identified complexType and it worked correctly. However, that
> > method is undesirable for my Jaxb definition of my service.
> >
> > Thanks,
> > Eric
>
>
