Service Control generation question....

[Chad Schoettger <ch...@gmail.com>]

So I'm working some new drt's for the webservice system control and
have run into a bug but I'm not sure how to classify it:

It occurs when I try to generate a service control from the
wsm-samples/webparams webservice's wsdl.


The annotated web service method is:
---------------------------------------------------------------------------------------------
@WebMethod
 public int updatePhoneNumbers(
            Phone phone,
            @WebParam(name="address1", header=true,
mode=WebParam.Mode.INOUT) AddressHolder addressHolder1,
            @WebParam(name="address2", header=true,
mode=WebParam.Mode.OUT) AddressHolder addressHolder2
    ) { .... }
------------------------------------------------------------------------------------------------

The WSDL is attached.

The generated webservice control method is:
-----------------------------------------------------------------------------------------------
public void UpdatePhoneNumbers(org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address>
address1, web.webparam.Phone phone, javax.xml.rpc.holders.IntHolder
return, org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address>
address2) throws Exception;
-----------------------------------------------------------------------------------------------

When the generated webservice control is compiled, apt blows up due to
the 'return' parameter name in the arg list.

Questions:

1) Is the control method being generated correctly? Should the
'return' parameter be the return value for the generated method? like:

public int UpdatePhoneNumbers(org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address>
address1, web.webparam.Phone phone,
org.apache.beehive.wsm.databinding.GenericHolder<web.webparam.Address>
address2) throws Exception;


2) If the method is being generated correctly - it seems the proper
fix would be to modify the ExtensionGenerator class to check for param
names which are Java keywords and modify them to non-keywords so that
the control can be compiled.  Or would the proper fix be to modify the
wsm model to correctly 'encode' the param as a non-java keyword?

Thanks for any input on this.  Once I have determined where the fix
needs to be made I will file a bug.