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: <tuscany-dev@ws.apache.org>
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: <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.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: <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]
>> > >
>> > >
>> >
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
