Bug submitted as AXIS2-2246
Amila Suriarachchi wrote: > > On 2/23/07, tgb <[EMAIL PROTECTED]> wrote: >> >> >> As evidence of my assertion on the "correctness" of no namespace for >> "parts", >> WS-I Basic 1.0 states: >> >> "4.7.20 Part Accessors >> For rpc-literal envelopes, WSDL 1.1 is not clear what namespace, if any, >> the >> accessor elements for parameters and return value are a part of. >> Different >> implementations make different choices, leading to interoperability >> problems. >> >> R2735 An ENVELOPE described with an rpc-literal binding MUST place the >> part >> accessor elements for parameters and return value in no namespace. >> >> R2755 The part accessor elements in a MESSAGE described with an >> rpc-literal >> binding MUST have a local name of the same value as the name attribute of >> the corresponding wsdl:part element. >> >> Settling on one alternative is crucial to achieving interoperability. The >> Profile places the part accessor elements in no namespace as doing so is >> simple, covers all cases, and does not lead to logical inconsistency. " >> >> http://www.ws-i.org/Profiles/BasicProfile-1.2.html >> http://www.ws-i.org/Profiles/BasicProfile-1.2.html >> >> This assumes WS-I basic complience is a goal for Axis2 which I'm sure is >> the >> case. Should I submit a bug? > > > thanks Tim, please log a jira. I'll fix it to use no namespace. > > Tim >> >> >> >> tgb wrote: >> > >> > There appears to be two problems. The most obvious is that the >> > RPC-literal message sent by the generated client and accepted by the >> > generated service is incorrect - or so I believe. The following >> message >> > body is sent for the various test cases I have tried - string, complex >> > type, nested complex type. >> > >> > <soapenv:Body> >> > <ns:OperationName> >> > <ns:PartName> >> > .............content..... >> > </ns:PartName> >> > </ns:OperationName> >> > </soapenv:Body> >> > >> > but it should be: >> > >> > <soapenv:Body> >> > <ns:OperationName> >> > <PartName> >> > .............content..... >> > </PartName> >> > </ns:OperationName> >> > </soapenv:Body> >> > >> > PartName should be a non qualified name. Axis 1.3 did it this way, and >> > other sources support this as being the correct form for rpc-literal. >> > >> > The second problem that I have yet to narrow down is that with a much >> more >> > complex type, the generated client sends a message with a body like >> this >> > where the "part" element is not present: >> > >> > <soapenv:Body> >> > <ns:OperationName> >> > .............content..... >> > </ns:OperationName> >> > </soapenv:Body> >> > >> > One other differnce that may be a factor is that my complex service is >> one >> > way. >> > >> > I have attached the WSDL I'm using for the test cases in case someone >> can >> > point out my obvious error. >> > >> > Thanks, >> > Tim >> > >> > >> > >> > >> > tgb wrote: >> >> >> >> Thanks, that makes sense. I understand the workaround for getting the >> >> service to show the correct WSDL. >> >> >> >> However, there seems to be a problem with the client codegen for >> >> rpc/literal. So far I have only managed to make it work correctly >> with >> >> parameter that has a simple type (I tried xs:string) When I change >> the >> >> type of the parameter to complex type, the client no longer adds the >> >> "part" element to the SOAP message it sends. Instead the "operation" >> >> element contains the complex data directly as if the SOAP message was >> a >> >> document literal style message. >> >> >> >> I am using the axis2 eclipse codegen plugin 1.1.1 with the default >> option >> >> (ie adb generation). I'll attach the WSDLs once I think I have a >> >> reproducible case >> >> >> >> Tim >> >> >> >> >> >> Amila Suriarachchi wrote: >> >>> >> >>> hi, >> >>> In codegeneration with wsdl, we convert the rpc style wsdl in to >> >>> document >> >>> style (similar in messages) by generating the elements for rpc type >> >>> messages. And finally save the wsdl file to resource directory. When >> >>> saving >> >>> the wsdl file back it serializes the generated axis service object >> >>> structure >> >>> instead of saving the origianl wsdl as it is. That is the reason why >> you >> >>> get >> >>> a wsdl which is converted to document style. So can you please >> replace >> >>> your >> >>> saved wsdl in resource folder with the original wsdl and see. >> >>> On the other hand axis2 generates a wsdl only if the Message receiver >> is >> >>> one >> >>> of RPCMessageReceivers. but when generating the code from the wsdl it >> >>> creates a custom message receiver for the given wsdl file. >> >>> >> >>> Amila. >> >>> -- >> >>> Amila Suriarachchi, >> >>> WSO2 Inc. >> >>> >> >>> >> >> >> >> >> > http://www.nabble.com/file/6694/Axis2RPCLiteralTest.wsdl >> > Axis2RPCLiteralTest.wsdl >> > >> >> -- >> View this message in context: >> http://www.nabble.com/RPC-WSDL---Codegen--tf2593238.html#a9113880 >> Sent from the Axis - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Amila Suriarachchi, > WSO2 Inc. > > -- View this message in context: http://www.nabble.com/RPC-WSDL---Codegen--tf2593238.html#a9114466 Sent from the Axis - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
