• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Webservice deployment failed

 
Poornima Sharma
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Friends,

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



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
Sheriff
Posts: 9934
113
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And which error do you get?
 
Ivan Krizsan
Ranch Hand
Posts: 2198
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

Best wishes!
 
Poornima Sharma
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 310
1
Java Linux Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
try adding @RequestWrapper and @ResponseWrapper to second @WebMethod

 
Poornima Sharma
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 310
1
Java Linux Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

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
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot, your logic makes sense.
 
Mikalai Zaikin
Ranch Hand
Posts: 3332
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

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




 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic