Is there a way I can instruct my JAX-WS web service client to ignore WS-Addressing header elements present in web service response?

My Environment:
JAX-WS web service client - deployed to WAS 7.0.0.9
JAX-WS Web service client - uses thin client com.ibm.jaxws.thinclient_7.0.0.jar
The web service (hosted on oracle soa suite) is sending WS-Addressing headers in the response. The header elements present in the web service response are ( <wsa:MessageID> and <wsa:ReplyTo> )
My JAX-WS web service client throws the following exception when it receives the web servcie response:
Exception in thread "P=991633:O=0:CT" javax.xml.ws.WebServiceException: org.apache.axis2.AxisFault: A required header representing a Message Addressing Property is not present
at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:175)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:70)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:128)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:572)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.doInvoke(AxisInvocationController.java:123)
at org.apache.axis2.jaxws.core.controller.impl.InvocationControllerImpl.invoke(InvocationControllerImpl.java:93)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:338)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invoke(JAXWSProxyHandler.java:159)
at $Proxy28.process(Unknown Source)
at TestBOD.main(TestBOD.java:58)
Caused by: org.apache.axis2.AxisFault: A required header representing a Message Addressing Property is not present
at org.apache.axis2.addressing.AddressingFaultsHelper.triggerAddressingFault(AddressingFaultsHelper.java:373)
at org.apache.axis2.addressing.AddressingFaultsHelper.triggerMessageAddressingRequiredFault(AddressingFaultsHelper.java:299)
at org.apache.axis2.handlers.addressing.AddressingInHandler.checkForMandatoryHeaders(AddressingInHandler.java:289)
at org.apache.axis2.handlers.addressing.AddressingInHandler.extractAddressingInformation(AddressingInHandler.java:274)
at org.apache.axis2.handlers.addressing.AddressingInHandler.invoke(AddressingInHandler.java:153)
at org.apache.axis2.engine.Phase.invoke(Phase.java:318)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:268)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:175)
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:363)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:416)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:567)
My further investigation tells me that JAX-WS runtime is looking for <wsa:action> WS-Addressing header element in the web service response, as the web service response does not contain <wsa:action> element its throwing the above exception.

I tried to disable WS-Addressing on my web service client with ( AddressingFeature , SubmissionAddressingFeature ) as discussed in the below urls but it seems to have no effect.
http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Finfo%2Fae%2Fae%2Ftwbs_wsa_disable.html
http://jax-ws.java.net/2.2.1/docs/wsaddressing.html#On_the_client_side

I tried both ways i.e.programmatically on the client code as well as specifying annotation @Addressing, @SubmissionAddressing on the client end point.

I'm not sure if <wsa:action> WS-Addressing header is a must header to be present in the web service response but being a consumer of the web service I don't have much control on the web service . But if <wsa:action> is a must header element then i'll have to initiate a discussion with web service hosting group.

So essentially I'm looking for a way to instruct my web service client to ignore WS-Addressing headers present in the web service response. Any better alternatives are most welcome.

I would recommend opening a PMR with IBM service to determine what the proper course of action is.

It would probably be good to look at both the request and response messages. If configured properly (policy sets appropriately configured on the client), then you should see WS-Addressing headers on both the request and the response and the required headers (yes Action is one of them) should be present.

I would recommend opening a PMR with IBM service to determine what the proper course of action is.

It would probably be good to look at both the request and response messages. If configured properly (policy sets appropriately configured on the client), then you should see WS-Addressing headers on both the request and the response and the required headers (yes Action is one of them) should be present.

Going back to the procedure discussed in the below link
http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Finfo%2Fae%2Fae%2Ftwbs_wsa_disable.html

If you look at the results of this procedure:
Results
By completing this task, you disabled the WS-Addressing support. Disabling WS-Addressing on clients prevents WebSphere® Application Server sending WS-Addressing message addressing properties in the SOAP header of outbound Web service messages. Disabling WS-Addressing on servers additionally prevents WebSphere Application Server processing WS-Addressing MAPs in incoming SOAP headers.
The results section does not talk anything about processing WS-Addressing MAPs in incoming SOAP headers on the service client side when WS-Addressing is disabled on clients.

Going back to the procedure discussed in the below link
http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Finfo%2Fae%2Fae%2Ftwbs_wsa_disable.html

If you look at the results of this procedure:
Results
By completing this task, you disabled the WS-Addressing support. Disabling WS-Addressing on clients prevents WebSphere® Application Server sending WS-Addressing message addressing properties in the SOAP header of outbound Web service messages. Disabling WS-Addressing on servers additionally prevents WebSphere Application Server processing WS-Addressing MAPs in incoming SOAP headers.
The results section does not talk anything about processing WS-Addressing MAPs in incoming SOAP headers on the service client side when WS-Addressing is disabled on clients.

If I understand your other question correctly, I am using the built in Web Services engine. I created my client using the tools in RAD to generate the client from a WSDL. I don't believe I have done anything directly with Axis2 engine or library.

If I understand your other question correctly, I am using the built in Web Services engine. I created my client using the tools in RAD to generate the client from a WSDL. I don't believe I have done anything directly with Axis2 engine or library.

Hi, ok, I am going to deploy my example to that version of WAS and see what I get. By default the WS-Addressing on the client is disabled. You may want to look at this link http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Finfo%2Fae%2Fae%2Ftwbs_wsa_disable.html to see if it helps you. I'll post back after I test my application out.

Hi, ok, I am going to deploy my example to that version of WAS and see what I get. By default the WS-Addressing on the client is disabled. You may want to look at this link http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Finfo%2Fae%2Fae%2Ftwbs_wsa_disable.html to see if it helps you. I'll post back after I test my application out.

Hi, I was able to get a simple Hello World example working. The client was automatically generated with the ws-addressing pieces. Change the policy set for the ws-addressing to not be required made the application worked correctly.

Hi, I was able to get a simple Hello World example working. The client was automatically generated with the ws-addressing pieces. Change the policy set for the ws-addressing to not be required made the application worked correctly.

Hey Brian, I took a look at the InfoCenter link you mentioned. I haven't tried to programmatically disable WS-Addressing (that will be soon) but that page says by default WS-Addressing support is disabled by default so I'm not sure if this will fix. I will give it a try a none the less just to see.

You mentioned that could also be done through the policy set. I have tried a policy set that does not include WS-Addressing, a policy set where WS-Addressing is in a disabled state, and a policy set with WS-Addressing enabled but not mandatory. Do you have an example policy set that would accomplish what you're describing.

Thanks again for the help. I've been at this for a couple days now and do appreciate the second set of eyes checking my work.

Hey Brian, I took a look at the InfoCenter link you mentioned. I haven't tried to programmatically disable WS-Addressing (that will be soon) but that page says by default WS-Addressing support is disabled by default so I'm not sure if this will fix. I will give it a try a none the less just to see.

You mentioned that could also be done through the policy set. I have tried a policy set that does not include WS-Addressing, a policy set where WS-Addressing is in a disabled state, and a policy set with WS-Addressing enabled but not mandatory. Do you have an example policy set that would accomplish what you're describing.

Thanks again for the help. I've been at this for a couple days now and do appreciate the second set of eyes checking my work.

If it is disabled and you are not using it then I cannot understand why it would not work. Please disable it in the application from the link referenced. You could also generate the client and change the WSDL to set the requirement to false (http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Ftwbs_wsa_dep.html). If that does not work, I am afraid that tracing will need to be enabled to understand what is going in the web services engine. For that you probably want to talk with someone from the IBM Support Center in your country.

You may also want to try a very simple example like this one from JBoss, but it should work the same under WAS. The generation of the classes and WSDL can be done by right clicking the selecting web services from the menu. You may want to do this anyway just to see if there is something in your environment that may be blocking this from working correctly.
https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_Web_Platform/5/html/JBoss_WS_CXF_User_Guide/ch05.html

If it is disabled and you are not using it then I cannot understand why it would not work. Please disable it in the application from the link referenced. You could also generate the client and change the WSDL to set the requirement to false (http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Ftwbs_wsa_dep.html). If that does not work, I am afraid that tracing will need to be enabled to understand what is going in the web services engine. For that you probably want to talk with someone from the IBM Support Center in your country.

You may also want to try a very simple example like this one from JBoss, but it should work the same under WAS. The generation of the classes and WSDL can be done by right clicking the selecting web services from the menu. You may want to do this anyway just to see if there is something in your environment that may be blocking this from working correctly.
https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_Web_Platform/5/html/JBoss_WS_CXF_User_Guide/ch05.html

I didn't find a way to handle this on WebSphere side (My web service client is deployed on WebSphere).

As as a temporary fix I asked the web service provider(deployed on Weblogic server) not to send any ws-addressing information in the soap response. But this is not a solution i'm looking at.

Brian:
1) I'm using the default behavior so assuming I'm not overriding the built in IBM Web Services engine
2) I'm curious on the 'simple Hello World example' test case you tried: Did your example ignore the ws-addressing headers present in the web service response?

Because I was able to stop generating the ws-addressing headers in the web service request (using policy sets or annotations) but didn't find a way to ignore the headers received in the web service response.

I didn't find a way to handle this on WebSphere side (My web service client is deployed on WebSphere).

As as a temporary fix I asked the web service provider(deployed on Weblogic server) not to send any ws-addressing information in the soap response. But this is not a solution i'm looking at.

Brian:
1) I'm using the default behavior so assuming I'm not overriding the built in IBM Web Services engine
2) I'm curious on the 'simple Hello World example' test case you tried: Did your example ignore the ws-addressing headers present in the web service response?

Because I was able to stop generating the ws-addressing headers in the web service request (using policy sets or annotations) but didn't find a way to ignore the headers received in the web service response.

I eventually opened a PMR about this problem and the response back from L3 support was there is no way to ignore the WS-Addressing headers using configuration. Disabling WS-Addressing on the client only prevents the headers from being sent on the request. If those headers come back on the response, WAS will process them and will expect them to conform to the spec.

We were left with these options

1) Get the service provider to stop sending any WS-Addressing headers.
2) Get the service provider to send all the needed headers and start using WS-Addressing.
3) Create a custom handler to intercept the message before WAS begins to process it and remove the problem-causing headers. I forget what kind of handler they mentioned.

Another option that someone else suggested to me was to treat the service provider as XML over HTTP and forget using a JAX-WS client. Needless to say both of cringed at that idea but it could do the trick if absolutely needed.

We were able to go with option 1 fortunately. I only hope you can get the same lucky break.

I eventually opened a PMR about this problem and the response back from L3 support was there is no way to ignore the WS-Addressing headers using configuration. Disabling WS-Addressing on the client only prevents the headers from being sent on the request. If those headers come back on the response, WAS will process them and will expect them to conform to the spec.

We were left with these options

1) Get the service provider to stop sending any WS-Addressing headers.
2) Get the service provider to send all the needed headers and start using WS-Addressing.
3) Create a custom handler to intercept the message before WAS begins to process it and remove the problem-causing headers. I forget what kind of handler they mentioned.

Another option that someone else suggested to me was to treat the service provider as XML over HTTP and forget using a JAX-WS client. Needless to say both of cringed at that idea but it could do the trick if absolutely needed.

We were able to go with option 1 fortunately. I only hope you can get the same lucky break.

My next option was to open a PMR but I got the answer from you at the right time.

As I mentioned in my earlier post, I'm currently using option#1 as a temporary fix but this option would not allow us to realize certain ws-addressing use cases. ( though i'm not using any ws-addressing use cases in my application )

For my case (if possible and easy) I feel option#2 would be ideal as required ws-addressing headers are exchanged. Will keep you posted once option#2 is tried.

My next option was to open a PMR but I got the answer from you at the right time.

As I mentioned in my earlier post, I'm currently using option#1 as a temporary fix but this option would not allow us to realize certain ws-addressing use cases. ( though i'm not using any ws-addressing use cases in my application )

For my case (if possible and easy) I feel option#2 would be ideal as required ws-addressing headers are exchanged. Will keep you posted once option#2 is tried.

Did you achieve any success on this issue? I am also facing the same problem. The addressing was not mandated on WSDL and the Client i have is failing on the messaging headers in the response from Service.