Webservice deployment failed

[Poornima Sharma]

Hi Friends,

I wrote a simple webservice program and used glassfish container to deploy it, but it failed. The following is the code:-

@WebService(name="CustomerService" , portName="CustomerService",targetNamespace="http://www.customer.com")
public class Customer {
    
    public String getCustomer(@WebParam(name="id1") int id) throws Exception
    {
        return "customer data";
    }
  
    @WebMethod(operationName="getCustomerByName")
    public String getCustomer(String id) throws Exception
    {
        return "customer data";
    }
    
}

The above code runs file if i remove @WebParam(name="id1") or if I make it @WebParam. But it gives error if I use @WebParam(name="id1"). I tried several combinations but it did not worked. It seems that there is some conflict in generating wsdl but I could not make out what is the reason.

PS:- I have used same method names, that should work if I have given the operationName in @WebMethod annotation.

Thanks,

[Roel De Nijs]

And which error do you get?

[Ivan Krizsan]

Hi!
You cannot customize parameter names when using Document/Literal binding.
By adding the following annotation to the class, you change the binding style to RPC/Literal Wrapped, with which you are free to name the parameters as you wish:

...
@WebService(name="CustomerService" , portName="CustomerService",targetNamespace="http://www.customer.com")  
@SOAPBinding( parameterStyle=SOAPBinding.ParameterStyle.WRAPPED, style=SOAPBinding.Style.RPC, use=SOAPBinding.Use.LITERAL)
public class Customer { 
...

Best wishes!

[Poornima Sharma]

Hi Ivan,

I am able to customize the parameter name using @WebParam, provided I am using altogether different method name in a WebService class. But in my given example I have used 2 methods that are overloaded and are having different operationName so that they dont conflict in wsdl creation.

Thanks,

[Rajeev Rnair]

try adding @RequestWrapper and @ResponseWrapper to second @WebMethod

 @RequestWrapper(className="GetCustomerRequest")
 @ResponseWrapper(className="GetCustomerResponse")

[Poornima Sharma]

Hi Rajeev,

Thanks for your reply. Your solution worked, but i could not make out why it was not working earlier and why did it worked after adding wrapper.

Thanks again,

[Rajeev Rnair]

great ! In document / literal / wrapped mode, the wrapper JAXB beans will be generated based on method name. so you will have issues with overloaded methods.
hence you have to use annotations for @RequestWrapper and @ResponseWrapper.
By default the mode is document / literal / wrapped.
If you add annotation

@SOAPBinding(style=SOAPBinding.Style.DOCUMENT,
        parameterStyle=SOAPBinding.ParameterStyle.BARE,
        use= SOAPBinding.Use.LITERAL)

the overloading will work without @ResponseWrapper / @RequestWrapper annotations.

(i got all this info from Mikalai Zaikin's notes. credit goes to him for providing so much internals !

[Poornima Sharma]

Thanks a lot, your logic makes sense.

[Mikalai Zaikin]

Rajeev Rnair wrote:great ! In document / literal / wrapped mode, the wrapper JAXB beans will be generated based on method name. so you will have issues with overloaded methods.
hence you have to use annotations for @RequestWrapper and @ResponseWrapper.
By default the mode is document / literal / wrapped.
If you add annotation

@SOAPBinding(style=SOAPBinding.Style.DOCUMENT,
        parameterStyle=SOAPBinding.ParameterStyle.BARE,
        use= SOAPBinding.Use.LITERAL)

the overloading will work without @ResponseWrapper / @RequestWrapper annotations.

(i got all this info from Mikalai Zaikin's notes. credit goes to him for providing so much internals !

@Rajeev, thank you for your kind words !

@Poornima, please take a look at JAX-WS 2.2 specification, section "3.6.2.1 Document Wrapped" - I copied most important paragraphs related to your case:

...
For the purposes of utilizing the JAXB mapping, each method is converted to two Java bean classes: one for the method input (henceforth called the request bean) and one for the method output (henceforth called the response bean). Application’s programming model doesn’t use these bean classes, so the applications need not package these classes. JAX-WS implementations may generate these classes dynamically as specified in this section.
...
In the absence of customizations, the wrapper request bean class MUST be named the same as the method and the wrapper response bean class MUST be named the same as the method with a “Response” suffix. The first letter of each bean name is capitalized to follow Java class naming conventions.
...
The javax.xml.ws.RequestWrapper and javax.xml.ws.ResponseWrapper annotations MAY be used to customize the name of the generated wrapper bean classes.
...
Generated bean classes must have unique names within a package and MUST NOT clash with other classes in that package. Clashes during generation MUST be reported as an error and require user intervention via name customization to correct. Note that some platforms do not distiguish filenames based on case so comparisons MUST ignore case.

This means that you can not have two methods with same name without specifying customizations. You have to use RequestWrapper and ResponseWrapper annotations on overloaded methods.

NOTE: The default (your code example) combination for JAX-WS 2 is DOCUMENT/LITERAL/WRAPPED

Best regards,
MZ