Hi Dan, Actually, in Muse 2.0, wsdl2java did work for wsdls that imported other wsdls. It only started throwing the NotDocLiteral error since 2.1. I'm not sure what was changed in it for 2.1. Fortunately, I have a copy of Muse 2.0, so I've been using its version of wsdl2java to generate the capability and proxy classes from my wsdls, even when we use 2.2 for everything else.
I haven't been able to use wsdl2java in 2.1 and 2.2 because it became tedious to copy over the message elements and make the necessary namespace modifications in them. Forgetting to update one namespace reference became difficult to pinpoint. Plus, the wsdls are generated from another team, so at some point, I can no longer modify the wsdls just so they can be processed successfully by wsdl2java. I understand the limitation you described though with WSDL4J. Hopefully we can find some resolution for this soon. -----Original Message----- From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 7:13 AM To: [email protected] Subject: RE: NotDocLiteral Error The behavior has been present since Muse 2.0 - the issue is the way we resolve all the WSDL content. WSDL4J doesn't give us access to the schemas/types, so we have to resolve the WSDL using DOM in order to look through the XSD definitions. When resolving the WSDL, we copy in the <types/> section, but not the <message/>s, because they would all of a sudden have a different namespace. We could keep all of the WSDLs in some kind of tree rather than merging them together, but this would be a lot more resource intensive (and a lot more work); because of that, we decided the simplest thing would be to copy in the <message/> elements. We already have to copy-and-paste the <operation/> elements because WSDL 1.1 does not have inheritance, so the addition of the <message/> elements wasn't seen as a major inconvenience. The code for WSDL resolution is in org.apache.muse.ws.wsdl.WsdlUtils (createWSDL() is the starting point). If you have ideas on how to efficiently merge or resolve the WSDL so that <message/>s and <types/> can be resolved from imported WSDLs, we can always change that code to handle it. Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 04/02/2007 03:35:04 AM: > Hi Dan, > I'm a bit confused. According to the WSDL 1.1 spec: > > "The following types of definitions contained in a WSDL document may be > referenced: > WSDL definitions: service, port, message, bindings, and portType > ... > The use of the import element allows the separation of the different > elements of a service definition into independent documents, which can > then be imported as needed. This technique helps writing clearer service > definitions, by separating the definitions according to their level of > abstraction. It also maximizes the ability to reuse service definitions > of all kinds. As a result, WSDL documents structured in this way are > easier to use and maintain." > > This contradicts your statement: > > "...when you 'resolve' a WSDL by importing the WSDLs mentioned in its > <import/> elements, the <message/> elements get moved from one namespace > (in this case, WS-MEX) to another (your custom namespace)..." > > So beginning with Muse 2.2.0, having to copy the message elements from > one wsdl to another defeats the purpose of the "import" feature for WSDL > 1.1. > > This reminds me of the old C programming style were code is "inlined" at > compile time, versus the C++/Java style of include/imports so that code > in other APIs can be referenced without having to be rewritten. > > > > -----Original Message----- > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] > Sent: Friday, March 30, 2007 5:42 AM > To: [email protected] > Subject: Re: NotDocLiteral Error > > The problem has to do with WSDL formatting - you need to have all of > your <message/> elements in your actual WSDL (not imported). The problem > is that the 'name' attribute on <message/> elements is not qualified, so > it takes whatever namespace is in the current WSDL; well, when you > 'resolve' > a WSDL by importing the WSDLs mentioned in its <import/> elements, the > <message/> elements get moved from one namespace (in this case, WS-MEX) > to another (your custom namespace), and WSDL4J can't resolve them. > > All you need to do is copy the <message/> elements in. It's still fine > to keep the actual schema definitions in separate XSD files. Once you > move the <message/> elements, change the 'message' attributes on your > <operation/> elements (below) to use the target namespace of your WSDL, > not wsmex-w. > > Dan > > > > "Mrityunjay Hubli \(mjay\)" <[EMAIL PROTECTED]> wrote on 03/30/2007 > 06:52:18 > AM: > > > Hi All, > > > > I have the following operation in my wsdl > > > > <wsdl:import namespace="http://schemas.xmlsoap.org/ws/2004/09/mex"; > > location="WS-MetadataExchange-2004_09.wsdl"/> > > ... > > <wsdl:operation name="GetMetadata"> > > <wsdl:input name="GetMetadataMsg" > > message="wsmex-w:GetMetadataMsg" > > wsa:Action="http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata"/> > > <wsdl:output name="GetMetadataResponseMsg" > > message="wsmex-w:GetMetadataResponseMsg" > > > wsa:Action="http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadataRespons > > e"/> > > </wsdl:operation> > > > > ... > > > > In WS-MetadataExchange-2004_09.wsdl the messages are defined as : > > <wsdl:message name="GetMetadataMsg"> > > <wsdl:part name="body" element="tns:GetMetadata"/> > > </wsdl:message> > > <wsdl:message name="GetMetadataResponseMsg"> > > <wsdl:part name="body" element="tns:Metadata"/> > > </wsdl:message> > > > > When I run wsdl2java, I get the following error: > > java.lang.RuntimeException: [ID = 'NotDocLiteral'] The WSDL operation > > 'GetMetada > > ta' is not doc-literal because it defines a message with more than one > > message p > > art for its SOAP Body. The SOAP Body of a doc-literal message should > > contain one > > root request element (with the operation name) with zero or more > child > > elements > > (the parameters). > > > > I have Muse version 2.2.0 > > > > Any ideas about what could be the problem ? > > > > Thanks, > > M'Jay > > > > > --------------------------------------------------------------------- > 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]
