[jira] Reopened: (TUSCANY-1142) Need to allow generation of wrapped Java intf from doc-lit-wrap WSDL with named complexType

["Scott Kurz (JIRA)" <tu...@ws.apache.org>]

     [ https://issues.apache.org/jira/browse/TUSCANY-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Kurz reopened TUSCANY-1142:
---------------------------------


I haven't tested the very latest code but by inspection and trying a recent build, I'd say this is unresolved.

If you take this WSDL as an example:
sca/modules/wsdl2java/src/test/resources/AccountService.wsdl

Here is an example

The operation:
        <wsdl:operation name="getAccountReportBare1Complex">

with input wrapper elem:
            <xsd:element name="getAccountReportBare1Complex" type="account:AccountRequest"/>

should be generated in the wrapped style.  Today I believe non-wrapped Java is still being generated.

--------------

One point that Yang and I missed in our original comments on this JIRA is that we need to make sure we do NOT 
try to generate wrapped Java when the input element is of a single type.     We might add that as check #5 in Yang's suggest
list then:

5) make sure element is of complexType   (or go further and say complexType defined by <sequence>????)

The current code does not have this problem and correctly detects this as non-wrapped, for example operation:  getAccountReportBare1Simple
in the same WSDL.

Just mentioning this since I had missed this case in my original writeup, which Tuscany is already handling correclty.   Don't want to lose this.


> Need to allow generation of wrapped Java intf from doc-lit-wrap WSDL with named complexType 
> --------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-1142
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1142
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Tools
>    Affects Versions: Java-SCA-M2
>            Reporter: Scott Kurz
>             Fix For: Java-SCA-1.0
>
>
> Our WSDL2Java tool maps the following WSDL pattern onto a non-wrapped Java interface even 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;
>                 }   ....
> As I claim in this JIRA, TUSCANY-1019, it would be nice to ALSO have the ability to generate a non-wrapped Java interface from the given WSDL pattern, but we should also allow for generation of a wrapped interface (the wrapped by my guess should be the default).
> Yang Zhong posted this reply in agreement to the Tuscany dev list.
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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