Ok.. we agree on the spec but as it turns out the code already seems to do what I was saying it should.. I was reading it incorrectly.
On 3/5/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, I think it's talking about the children this time, isn't it? :-). I assume it's an example of other structures contained by the wrapper. "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." Raymond ----- Original Message ----- From: "Scott Kurz" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, March 05, 2007 8:56 AM Subject: Re: bug in determing WSDL-> Java mapping style? > Raymond, > > By the same logic we went through before...... shouldn't we only be > checking > this for the wrapper element and not the child elements it wrappers? > > Scott > > On 3/5/07, Raymond Feng <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> By the JAX-WS 2.0 spec page 12: >> >> "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." >> >> It seems that Tuscany is doing the right thing. >> >> Thanks, >> Raymond >> >> ----- Original Message ----- >> From: "Scott Kurz" <[EMAIL PROTECTED]> >> To: <[email protected]> >> Sent: Monday, March 05, 2007 8:09 AM >> Subject: Re: bug in determing WSDL-> Java mapping style? >> >> >> > Here's a follow-up two months later to this thread..... >> > >> > We seem to need a small additional fix in >> > WSDLOperation$Wrapper.getChildElements(). >> > In this line we're again wrongly enforcing the requirement that the >> > wrapper >> > element can't have a reference on to the child element, which I think >> > should >> > be allowed to be a reference. >> > >> > if (childElement.getName() == null || >> > childElement.getRefName() != null) { >> > return null; >> > } >> > >> > Agreed? >> > Scott >> > >> > >> > On 1/3/07, Scott Kurz <[EMAIL PROTECTED]> wrote: >> >> >> >> 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: <[email protected] > >> >> > > 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.2is >> >> > > > 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: <[email protected]> >> >> > > >> 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.WSDLOperationwe >> 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] >> >> > > >> >> > > >> >> > >> >> >> > >> >> >> --------------------------------------------------------------------- >> 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]
