Thanks much for your help with this. I agree, it's technically not a bug. However, when you extend the sample below by making the IN parameter an INOUT parameter, you get 4 (!) parameters in the stub for each original parameter in the original web method. Thus, a method that has originally 5 parameters, for instance, will produce a stub with 20 parameters... Moreover, there doesn't seem to be a problem when using the "ENCODED" use, e.g. RPC/ENCODED. IMO, for usability reasons, it would definitely be nice to get back to the original method signature.
Cheers, -michael -----Original Message----- From: Jongjin Choi [mailto:[EMAIL PROTECTED] Sent: Monday, December 20, 2004 5:38 AM To: [EMAIL PROTECTED]; axis-dev@ws.apache.org Cc: Beehive Developers Subject: Re: More Axis questions... Michael, Your example looks like one of simple and extreme example of JAX-RPC. How the annotation is good for soap header processing... I think that this is not a bug of Axis but may be annoying for use. This is because the 'testMethodRequest' input message has two parts (in0, parameters) in the WSDL: <wsdl:message name="testMethodRequest"> <wsdl:part element="impl:in0" name="in0"/> <wsdl:part element="impl:testMethod" name="parameters"/> </wsdl:message> <wsdl:portType name="Blank"> <wsdl:operation name="testMethod"> <wsdl:input message="impl:testMethodRequest" name="testMethodRequest"/> <wsdl:output message="impl:testMethodResponse" name="testMethodResponse"/> <wsdl:fault message="impl:Exception" name="Exception"/> </wsdl:operation> </wsdl:portType> When doing wsdl2java, the two parts are mapped to parameters of java method, so we have public template.TestMethodResponse testMethod( java.lang.String in0, template.TestMethod parameters ) throws java.rmi.RemoteException, java.lang.Exception instead of public int testMethod( String in0, ) throws java.rmi.RemoteException, java.lang.Exception But at the messaging level, the deser and ser of message will be ok. Isn't it? It doesn't seem to be clear that the generated methods' signature should have latter form. I think that the annoying parameter 'template.TestMethod' can be removed if the Axis checks if it has nothing to serialize and omit it from the signature. But I'm afraid that this can hurt the backward portability. Generating another 'testMethod' whose signature looks like the latter would be another option. What do the axis team think about it? Modify the generated signature? Have convenient method generated? Or Let it as it is...? /Jongjin ----- Original Message ----- From: "Michael Merz" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Beehive Developers" <[EMAIL PROTECTED]> Sent: Saturday, December 18, 2004 3:23 AM Subject: FW: More Axis questions... I don't understand some of the behavior of wsdl2java when run against a running web service with "header" web parameters ("ParamDesc.setInHeader(true)"). The generated methods in the client stub look quite different from the original ones; in particular, they seem to have parameters that are not required: The original server side WebMethod (within a @WebService) in Beehive notation: public int testMethod( @WebParam(header=true) String s ) throws Exception Turned into the following method in the autogenerated client stub: public template.TestMethodResponse testMethod( java.lang.String in0, template.TestMethod parameters ) throws java.rmi.RemoteException, java.lang.Exception Instead, I would have expected something like: public int testMethod( String in0, ) throws java.rmi.RemoteException, java.lang.Exception [For WSDL and sources, see attachments.] The curiousities are: 1) the original had a return type int, the stub's return type is template.TestMethodResponse 2) the original had one formal parameter of type String, the stub has two parameters, one of type String and one of type template.TestMethodResponse 3) if I use INOUT or OUT params, even more formal parameters get added to testMethod's signature. Note that the change of parameter names from "s" to "in0" was expected. I'm not sure what the problem is, yet, and was just curious if there were any known issues around this. Also note that everything works fine if I set the "header" options to "false". Any ideas? Thanks much. Cheers, -michael
