OK, I see you used r491901 to fix this so I won't open a JIRA.
On 1/2/07, Scott Kurz <[EMAIL PROTECTED]> wrote:
Thanks Raymond, Should I open a JIRA? On 1/2/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Hi, Frank. > > I think you're right after reading the paragraph again. > > Scott, I'll adjust the code to fix the rule. > > Thanks, > Raymond > > ----- Original Message ----- > From: "Frank Budinsky" <[EMAIL PROTECTED]> > To: <tuscany-dev@ws.apache.org > > Sent: Tuesday, January 02, 2007 9:31 AM > Subject: Re: bug in determing WSDL-> Java mapping style? > > > > Hi Raymond, > > > > Just my 2-cents worth, but my reading of the quoted section 2.3.1.2 is > > that "they" in "furthermore, they must not be nillable" is referring > to > > the "wrapper elements", not the "child elements". > > > > Frank. > > > > "Raymond Feng" <[EMAIL PROTECTED]> wrote on 01/02/2007 12:12:00 PM: > > > >> Hi, Scott. > >> > >> JAX-WS spec 2.0 section 2.3.1.2 actually says: > >> > >> "The wrapper elements only contain child elements, they must not > contain > > > >> other structures such as wildcards (element or attribute), > xsd:choice, > >> substitution groups (element references are not permitted) or > > attributes; > >> furthermore, they must not be nillable." > >> > >> Please note the last phrase requires that the child elements must not > be > > > >> nillable. > >> > >> Thanks, > >> Raymond > >> > >> ----- Original Message ----- > >> From: "Scott Kurz" <[EMAIL PROTECTED] > > >> To: <tuscany-dev@ws.apache.org> > >> Sent: Tuesday, January 02, 2007 8:34 AM > >> Subject: bug in determing WSDL-> Java mapping style? > >> > >> > >> > Before opening a JIRA I thought I'd throw this out there to ensure > > it's > >> > really a bug. > >> > > >> > In code such as org.apache.tuscany.idl.wsdl.WSDLOperation we try to > >> > enforce > >> > the JAX-WS criteria for using "wrapper-style" mapping mentioned in > > JAX-WS > >> > 2.3.1.2. > >> > > >> > The WSDLOperation code has the spec statement as a comment: > >> > ..... > >> > * (v) The wrapper elements only contain child elements, they > must > > not > >> > contain other structures such as > >> > * wildcards (element or attribute), xsd:choice, substitution > > groups > >> > (element references are not permitted) or > >> > * attributes; furthermore, they must not be nillable. > >> > > >> > Our code, however, seems to go further and require that the child > > elements > >> > themselves are non-nillable in order to use wrapper-style mapping. > >> > > >> > So if I'd modified the example in Figure 2.1 of JAX-WS to look > like: > >> > > >> > <xsd:element name="setLastTradePrice"> > >> > <xsd:complexType> > >> > <xsd:sequence> > >> > <xsd:element name="tickerSymbol" nillable="true" > >> > type="xsd:string" /> > >> > <xsd:element name="lastTradePrice" nillable="true" > >> > type="xsd:float" /> > >> > </xsd:sequence> > >> > </xsd:complexType> > >> > </xsd:element> > >> > > >> > then the Tuscany runtime would assume I was working with a > >> > non-wrapped-style > >> > interface like: > >> > > >> > SetLastTradePriceResponse setLastTradePrice(SetLastTradePrice > >> > setLastTradePrice); > >> > > >> > Doesn't this seem incorrect? > >> > > >> > When I used the JAX-WS wsimport tool against a doc-lit-wrapped > style > > WSDL, > >> > I > >> > had no problem with nillable="true" on the child elements. I still > > > got > >> > wrapped-style Java. > >> > > >> > (A related but separate issue that I will open a JIRA for is the > fact > > that > >> > there is no option in Tuscany's WSDL2Java tooling to generate > > non-wrapped > >> > Java from doc-literal-wrapped WSDL.) > >> > > >> > Thanks, > >> > Scott > >> > > >> > >> > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
