[ https://issues.apache.org/jira/browse/TUSCANY-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Marino updated TUSCANY-1142: -------------------------------- Fix Version/s: (was: Java-SCA-Future) (was: Java-SCA-integration) Tooling-Future > 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-M2 > Reporter: Scott Kurz > Fix For: Tooling-Future > > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]