Re: More Axis questions...

[Jongjin Choi <gu...@hotmail.com>]

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" <mm...@bea.com>
To: <ax...@ws.apache.org>
Cc: "Beehive Developers" <be...@incubator.apache.org>
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