You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Scott Kurz <sc...@gmail.com> on 2007/02/24 16:58:12 UTC

WSDL->Java wrapped (vs. non-wrapped) with doc-lit-wrap WSDL with named complexType

I was wondering about the decision to have the WSDL2Java tool map the
following WSDL pattern onto a non-wrapped Java interface
when using doc-lit-wrapped WSDL:

...<types>
            ....
            <complexType name="getGreetings">
              <sequence>
                <element name="name" type="xsd:string"/>
              </sequence>
            </complexType>

            <element name="getGreetings" type="tns:getGreetings"/>
            ...
</types>

I noticed that wsimport seems to unwrap this and produce:

  getGreetings(String)

whereas our WSDL2Java treats this as non-wrapped and generates:

  getGreetings(getGreetings)

The key line of Tuscany code is:

org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.isWrapped()
   ....      if (typeMappingEntry.isAnonymous()) {
                    wrapped = true;
                }   ....


Are we interpreting differently Sec. 2.3.1.2 (iv) of the JAX-WS spec?, which
says:

(iv) The elements referred to by the input and output message parts
(henceforth referred to as wrapper 27
elements) are both complex types defined using the xsd:sequence compositor

Also, I'm realizing this maybe provides a (unintended?) way to solve the
issue I raised in:
http://issues.apache.org/jira/browse/TUSCANY-1019
(That is, assuming the runtime databinding code also calculates this as
"non-wrapped"; if not there is potentially another problem).

On the other hand I think it would be better to solve 1019 by providing an
explicit choice.

Also it seems there are a lot of WSDLs out there following the above "named
complexType" pattern, (or whatever it's called).

I'm wondering what Yang, Raymond, Sebastien and whoever else is interested
in the WSDL2Java tools thinks about this...

Thanks,
Scott Kurz

Re: WSDL->Java wrapped (vs. non-wrapped) with doc-lit-wrap WSDL with named complexType

Posted by Jean-Sebastien Delfino <js...@apache.org>.
Scott Kurz wrote:
> Yang,
> Do you think it would help for me to open a JIRA to support the named 
> types?
> Thanks,
> Scott
>
> On 2/24/07, Yang ZHONG <le...@gmail.com> wrote:
>>
>> Once binding is involved within WSDL2Java, one WSDL portType/message can
>> end
>> up with multiple Java classes respective to different bindings.
>> It mixes business logic and wire format :-(
>>
>> Assuming involving binding is de facto, and only one binding each WSDL
>> portType/message,
>> maybe we can change JavaInterfaceEmitter.isWrapped to an algorithm such
>> as:
>> 1. not wrapped if the style is not document or the use is not literal
>> 2. not wrapped if the message has more than one parts
>> 3. not wrapped if the part isn't element or its local name doesn't match
>> the
>> operation local name
>> 4. not wrapped if the operation name isn't unique within the portType
>>
>> Yes, I agree with Scott not to take isAnonymous() into account.
>>
>> On 2/24/07, Scott Kurz <sc...@gmail.com> wrote:
>> >
>> > I was wondering about the decision to have the WSDL2Java tool map the
>> > following WSDL pattern onto a non-wrapped Java interface
>> > when using doc-lit-wrapped WSDL:
>> >
>> > ...<types>
>> >            ....
>> >            <complexType name="getGreetings">
>> >              <sequence>
>> >                <element name="name" type="xsd:string"/>
>> >              </sequence>
>> >            </complexType>
>> >
>> >            <element name="getGreetings" type="tns:getGreetings"/>
>> >            ...
>> > </types>
>> >
>> > I noticed that wsimport seems to unwrap this and produce:
>> >
>> > getGreetings(String)
>> >
>> > whereas our WSDL2Java treats this as non-wrapped and generates:
>> >
>> > getGreetings(getGreetings)
>> >
>> > The key line of Tuscany code is:
>> >
>> >
>> org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.isWrapped 
>>
>> > ()
>> >   ....      if (typeMappingEntry.isAnonymous()) {
>> >                    wrapped = true;
>> >                }   ....
>> >
>> >
>> > Are we interpreting differently Sec. 2.3.1.2 (iv) of the JAX-WS spec?,
>> > which
>> > says:
>> >
>> > (iv) The elements referred to by the input and output message parts
>> > (henceforth referred to as wrapper 27
>> > elements) are both complex types defined using the xsd:sequence
>> compositor
>> >
>> > Also, I'm realizing this maybe provides a (unintended?) way to 
>> solve the
>> > issue I raised in:
>> > http://issues.apache.org/jira/browse/TUSCANY-1019
>> > (That is, assuming the runtime databinding code also calculates 
>> this as
>> > "non-wrapped"; if not there is potentially another problem).
>> >
>> > On the other hand I think it would be better to solve 1019 by 
>> providing
>> an
>> > explicit choice.
>> >
>> > Also it seems there are a lot of WSDLs out there following the above
>> > "named
>> > complexType" pattern, (or whatever it's called).
>> >
>> > I'm wondering what Yang, Raymond, Sebastien and whoever else is
>> interested
>> > in the WSDL2Java tools thinks about this...
>> >
>> > Thanks,
>> > Scott Kurz
>> >
>>
>>
>>
>> -- 
>>
>> Yang ZHONG
>>
>

Yes it will help. Thanks.

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Re: WSDL->Java wrapped (vs. non-wrapped) with doc-lit-wrap WSDL with named complexType

Posted by Scott Kurz <sc...@gmail.com>.
Yang,
Do you think it would help for me to open a JIRA to support the named types?
Thanks,
Scott

On 2/24/07, Yang ZHONG <le...@gmail.com> wrote:
>
> Once binding is involved within WSDL2Java, one WSDL portType/message can
> end
> up with multiple Java classes respective to different bindings.
> It mixes business logic and wire format :-(
>
> Assuming involving binding is de facto, and only one binding each WSDL
> portType/message,
> maybe we can change JavaInterfaceEmitter.isWrapped to an algorithm such
> as:
> 1. not wrapped if the style is not document or the use is not literal
> 2. not wrapped if the message has more than one parts
> 3. not wrapped if the part isn't element or its local name doesn't match
> the
> operation local name
> 4. not wrapped if the operation name isn't unique within the portType
>
> Yes, I agree with Scott not to take isAnonymous() into account.
>
> On 2/24/07, Scott Kurz <sc...@gmail.com> wrote:
> >
> > I was wondering about the decision to have the WSDL2Java tool map the
> > following WSDL pattern onto a non-wrapped Java interface
> > when using doc-lit-wrapped WSDL:
> >
> > ...<types>
> >            ....
> >            <complexType name="getGreetings">
> >              <sequence>
> >                <element name="name" type="xsd:string"/>
> >              </sequence>
> >            </complexType>
> >
> >            <element name="getGreetings" type="tns:getGreetings"/>
> >            ...
> > </types>
> >
> > I noticed that wsimport seems to unwrap this and produce:
> >
> > getGreetings(String)
> >
> > whereas our WSDL2Java treats this as non-wrapped and generates:
> >
> > getGreetings(getGreetings)
> >
> > The key line of Tuscany code is:
> >
> >
> org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.isWrapped
> > ()
> >   ....      if (typeMappingEntry.isAnonymous()) {
> >                    wrapped = true;
> >                }   ....
> >
> >
> > Are we interpreting differently Sec. 2.3.1.2 (iv) of the JAX-WS spec?,
> > which
> > says:
> >
> > (iv) The elements referred to by the input and output message parts
> > (henceforth referred to as wrapper 27
> > elements) are both complex types defined using the xsd:sequence
> compositor
> >
> > Also, I'm realizing this maybe provides a (unintended?) way to solve the
> > issue I raised in:
> > http://issues.apache.org/jira/browse/TUSCANY-1019
> > (That is, assuming the runtime databinding code also calculates this as
> > "non-wrapped"; if not there is potentially another problem).
> >
> > On the other hand I think it would be better to solve 1019 by providing
> an
> > explicit choice.
> >
> > Also it seems there are a lot of WSDLs out there following the above
> > "named
> > complexType" pattern, (or whatever it's called).
> >
> > I'm wondering what Yang, Raymond, Sebastien and whoever else is
> interested
> > in the WSDL2Java tools thinks about this...
> >
> > Thanks,
> > Scott Kurz
> >
>
>
>
> --
>
> Yang ZHONG
>

Re: WSDL->Java wrapped (vs. non-wrapped) with doc-lit-wrap WSDL with named complexType

Posted by Yang ZHONG <le...@gmail.com>.
Once binding is involved within WSDL2Java, one WSDL portType/message can end
up with multiple Java classes respective to different bindings.
It mixes business logic and wire format :-(

Assuming involving binding is de facto, and only one binding each WSDL
portType/message,
maybe we can change JavaInterfaceEmitter.isWrapped to an algorithm such as:
1. not wrapped if the style is not document or the use is not literal
2. not wrapped if the message has more than one parts
3. not wrapped if the part isn't element or its local name doesn't match the
operation local name
4. not wrapped if the operation name isn't unique within the portType

Yes, I agree with Scott not to take isAnonymous() into account.

On 2/24/07, Scott Kurz <sc...@gmail.com> wrote:
>
> I was wondering about the decision to have the WSDL2Java tool map the
> following WSDL pattern onto a non-wrapped Java interface
> when using doc-lit-wrapped WSDL:
>
> ...<types>
>            ....
>            <complexType name="getGreetings">
>              <sequence>
>                <element name="name" type="xsd:string"/>
>              </sequence>
>            </complexType>
>
>            <element name="getGreetings" type="tns:getGreetings"/>
>            ...
> </types>
>
> I noticed that wsimport seems to unwrap this and produce:
>
> getGreetings(String)
>
> whereas our WSDL2Java treats this as non-wrapped and generates:
>
> getGreetings(getGreetings)
>
> The key line of Tuscany code is:
>
> org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.isWrapped
> ()
>   ....      if (typeMappingEntry.isAnonymous()) {
>                    wrapped = true;
>                }   ....
>
>
> Are we interpreting differently Sec. 2.3.1.2 (iv) of the JAX-WS spec?,
> which
> says:
>
> (iv) The elements referred to by the input and output message parts
> (henceforth referred to as wrapper 27
> elements) are both complex types defined using the xsd:sequence compositor
>
> Also, I'm realizing this maybe provides a (unintended?) way to solve the
> issue I raised in:
> http://issues.apache.org/jira/browse/TUSCANY-1019
> (That is, assuming the runtime databinding code also calculates this as
> "non-wrapped"; if not there is potentially another problem).
>
> On the other hand I think it would be better to solve 1019 by providing an
> explicit choice.
>
> Also it seems there are a lot of WSDLs out there following the above
> "named
> complexType" pattern, (or whatever it's called).
>
> I'm wondering what Yang, Raymond, Sebastien and whoever else is interested
> in the WSDL2Java tools thinks about this...
>
> Thanks,
> Scott Kurz
>



-- 

Yang ZHONG