JAX WS: Change location of xmlns attribute

Question

JAX WS is generating the following (only a snippet shown):

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
   <S:Body>
      <ns2:capMessageResponse xmlns:ns2="http://www.########.com" xmlns:ns3="test:one:two:1.2" xmlns:ns4="test:one:two:three:1.1">
         <ns3:alert>
            <ns3:identifier>1247275</ns3:identifier>

Here is the method that generates that:

@WebMethod(operationName = "capMessage", action = "urn:getCapMessages")
    @WebResult(name = "alert", targetNamespace="test:one:two:1.2")
    public List<AlertType> getCapMessage(String messageIds,String uniqueId,boolean skipHtmlStrip) throws CommsMessageException {
        try {

What we need want to do is remove the capMessageResponse from the output and have xmlns attribtues move to the alert attribute.

Is there anyway to do this?

Answer 1

From the Java Method signature looks like you are using DOCUMENT/WRAPPED style. Can you confirm? If that is the case then with the current method signature it won't possible to do what you are hoping for.

If you create a new class to hold the method argument and switch to BARE style then you can get the output you are looking. Additionally you may need to create another class to hold the collection return value as well.

public List<AlertType> getCapMessage(CapMessageRequest request) throws ...

Answer 2

To achieve the output you want, you specify the following annotation on your service implementation bean

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

This annotation is only legal when your webservice binding is of the Document style (which is the default and what you're using already from the look of things).

A word of caution on this choice though

1. Your message payloads are not wrapped with the operation names anymore, this you already know/want

2. Directly as a result of 1. above you will not be able to use the same entity/argument type in another operation on the same web service as the dispatcher will not have any information to go on to successfully dispatch the message

3. Also as a result of 1(lack of relevant info), your webservice operation will be unable to accept more than one parameter