Bug 900634 (JBPAPP6-871) - [GSS] (6.3.0) JBossWS-CXF doesn't send fault message to a FaultTo endpoint when request-response message.
Summary: [GSS] (6.3.0) JBossWS-CXF doesn't send fault message to a FaultTo endpoint wh...
Alias: JBPAPP6-871
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web Services
Version: 6.1.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: DR6
: EAP 6.3.0
Assignee: Jim Ma
QA Contact:
URL: http://jira.jboss.org/jira/browse/JBP...
Depends On:
Blocks: JBPAPP6-978 1040731
TreeView+ depends on / blocked
Reported: 2012-06-14 13:19 UTC by Takayuki Konishi
Modified: 2018-11-28 20:39 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
If the `FaultTo` element of WS-Addressing was set to a WS client, the WS server did not send fault messages to the `FaultTo` destination. However, if the `ReplyTo` element was set, the WS server did send the responses to the `ResponseTo` destination. This bug was fixed in this version of JBoss EAP 6 with an update of Apache CXF.
Clone Of:
Last Closed: 2014-06-28 15:26:45 UTC
Type: Bug

Attachments (Terms of Use)
war with webservice using @Addressing throwing fault (4.36 KB, application/x-webarchive)
2013-09-24 13:41 UTC, Petr Sakař
no flags Details
request content (748 bytes, text/xml)
2013-09-24 13:42 UTC, Petr Sakař
no flags Details
request content oneway (746 bytes, text/xml)
2013-09-24 13:43 UTC, Petr Sakař
no flags Details
service interface java src (1.30 KB, text/x-java)
2013-09-24 13:52 UTC, Petr Sakař
no flags Details
service implementation java src (1.94 KB, text/x-java)
2013-09-24 13:53 UTC, Petr Sakař
no flags Details
TestCase (8.68 KB, text/x-java)
2013-09-26 19:00 UTC, Petr Sakař
no flags Details
project with arquillian testcase (10.59 KB, application/zip)
2014-04-01 14:34 UTC, Petr Sakař
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker JBPAPP6-871 0 Major Closed JBossWS-CXF doesn't send fault message to a FaultTo endpoint when request-response message. 2016-08-30 18:18:11 UTC
Red Hat Issue Tracker JBWS-3516 0 Major Closed JBossWS-CXF doesn't send fault message to a FaultTo endpoint when request-response message. 2016-08-30 18:18:11 UTC

Description Takayuki Konishi 2012-06-14 13:19:04 UTC
Help Desk Ticket Reference: https://na7.salesforce.com/500A000000A3sPI
project_key: JBPAPP6

When I set FaultTo element of WS-Addressing to a WS client but WS server doesn't sent fault messages to the FaultTo destination. On the other hand, when set ReplyTo element, the WS server sent responses to ResponseTo destination.

Comment 1 Takayuki Konishi 2012-06-14 13:20:50 UTC
Link: Added: This issue relates to JBWS-3516

Comment 2 Jason Greene 2012-07-31 19:35:51 UTC
Can we get a component update for this?

Comment 3 Alessio Soldano 2012-08-03 10:12:13 UTC
Link: Added: This issue is a dependency of JBPAPP-9438

Comment 4 Jim Ma 2012-08-09 14:04:30 UTC
RemoteIssueLink: Added: This issue links to "CXF-4382 (Web Link)"

Comment 5 Jan Martiska 2012-10-04 11:43:32 UTC
I can't verify that the fix works. I developed a simple jax-ws service with one method which throws a Fault, deployed it into EAP 6.0.1.ER2 and invoked it using curl.

This is the SOAP message sent to server:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        <Action xmlns="http://www.w3.org/2005/08/addressing">sayHelloWorldFrom</Action>
        <MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:f1b33789-4a21-447a-95fb-5ea15b0e4545</MessageID>
        <To xmlns="http://www.w3.org/2005/08/addressing">http://localhost:8080/jbpapp9342-1.0/HelloService</To>
        <ReplyTo xmlns="http://www.w3.org/2005/08/addressing"><Address>http://localhost:7778</Address></ReplyTo>
        <FaultTo xmlns="http://www.w3.org/2005/08/addressing"><Address>http://localhost:7777</Address></FaultTo>
  <ns:sayHelloWorldFrom xmlns:ns="http://test/">

For simplicity I had the "nc" application listening on ports 7777 and 7778 to check for the responses. Even though the webservice threw a Fault, the message was sent to port 7778, that means the ReplyTo endpoint - like this: 

[jmartisk@dhcp-4-145 ~]$ nc -lk 7778
Content-Type: text/xml; charset=ISO-8859-1
Accept: */*
User-Agent: Apache CXF 2.4.8-patch-01-redhat-1
Cache-Control: no-cache
Pragma: no-cache
Host: localhost:7778
Connection: keep-alive
Content-Length: 661

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><Action xmlns="http://www.w3.org/2005/08/addressing">http://test/HelloService/sayHelloWorldFrom/Fault/SOAPFaultException</Action><MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:5960a0dd-e4c7-4ed6-9649-62bef4f3dc06</MessageID><To xmlns="http://www.w3.org/2005/08/addressing">http://localhost:7777</To><RelatesTo xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:f1b33789-4a21-447a-95fb-5ea15b0e4545</RelatesTo></soap:Header><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>FAIL</faultstring></soap:Fault></soap:Body></soap:Envelope>

Comment 6 Jan Martiska 2012-10-05 07:50:09 UTC
For Oneway operations (similar issue - JBPAPP-9464) this works for me, but for two-way operations, it doesn't. Am I doing something wrong?

Comment 7 Misty Stanley-Jones 2012-11-05 05:34:40 UTC
Release Notes Docs Status: Added: Not Yet Documented

Comment 8 Anne-Louise Tangring 2012-11-13 20:07:41 UTC
Release Notes Docs Status: Removed: Not Yet Documented 
Docs QE Status: Removed: NEW 

Comment 9 Jim Ma 2013-01-09 11:02:39 UTC
Did you get some thing from port 7777 the faultTo port ? 

Comment 10 Jan Martiska 2013-01-09 11:08:30 UTC
No, nothing arrived there.

Comment 11 Jan Martiska 2013-01-09 11:44:29 UTC
Tried with 6.0.1.GA. Issue still present.

Comment 12 Jim Ma 2013-01-09 12:26:21 UTC
There is a test for the two way fault to test :https://svn.jboss.org/repos/jbossws/thirdparty/cxf/tags/cxf-2.4.9.jbossorg-1/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/MAPAggregator.java . Can you see any difference with you test case ?

Comment 13 Jan Martiska 2013-01-09 12:52:36 UTC
I am not sure if that is the correct link you meant, I don't see any test there. I found this: https://svn.jboss.org/repos/jbossws/thirdparty/cxf/tags/cxf-2.4.9.jbossorg-1/rt/ws/addr/src/test/java/org/apache/cxf/ws/addressing/soap/DecoupledFaultHandlerTest.java but that contains only a test for Oneway communication.

Comment 14 Jan Martiska 2013-01-09 12:58:38 UTC
@Addressing(enabled = true)
public class SimpleWebService { 
   public void throwFault() throws Exception {
      throw new Exception("This is a fatal error.");

This is what I use - just deploy and invoke it. If I add @Oneway annotation to the method, it works correctly, but this way it doesn't.

Comment 16 Jan Martiska 2013-01-10 08:59:09 UTC
It looks somewhat similar. I am not sure if I understand the test "testTwoWayFaultTo" correctly, but I don't see any check that the fault actually goes to the FaultTo endpoint. On the contrary, in "testOneWayFaultTo" I assume that the last line (the assertTrue) of the test is a check that the fault actually goes to the FaultTo endpoint. But I might be getting it wrong.

Comment 17 Jim Ma 2013-01-11 10:55:59 UTC
This line in WSAFaultToClientServerTest actually test if the server receives faultTo message and responses correctly :

assertTrue("The response from faultTo endpoint is expected and actual response is " 
           + new String(input.toByteArray()) , new String(input.toByteArray()).indexOf("The server sent HTTP status code :200") > -1);

Comment 18 Jan Martiska 2013-01-11 11:39:29 UTC
What is exactly that ByteArrayOutputStream named "input"? - I understand that this is a stream which collects messages from the Bus using a logging interceptor. But I don't know exactly which messages are supposed to arrive there (from which webservices - if it was the FaultTo endpoint ONLY, the test would be valid) - I would guess the message will arrive on the Bus - and therefore in the ByteArrayOutputStream - even if the fault is sent to the wrong endpoint, so the testcase would be written incorrectly, because it cannot distinguish which endpoint received the fault. But I might be mistaken in my understanding of the test case. I don't have much insight into how that testsuite works, but my manual reproducer shows that the fault is sent to ReplyTo endpoint..

Comment 19 Jim Ma 2013-01-14 03:23:16 UTC
If you look at the above line code to assert the response from the faultEndpoint, you'll find the requester actually can get the response result from faultTo endpoint. The http response code 200 is from faultToEndpoint , that means the server side successfully delivered the fault message to faultTo address, and faultTo endpoint response with http OK. You can look at the org.apache.cxf.systest.ws.addr_feature.FaultToEndpointServer to figure out what's the request/response from the faultTo Endpoint.  

Comment 23 Jim Ma 2013-09-09 15:14:09 UTC
This is already fixed in EAP 6.1.1, and we can verify it in EAP 6.2.

Comment 24 Rostislav Svoboda 2013-09-10 08:28:33 UTC
This will be verified during EAP 6.2.0 ER1 test cycle on both EAP 6.1.1 GA and EAP 6.2.0 ER1.

Target version will be modified accordingly to reflect correct version where the fix went.

Comment 25 Petr Sakař 2013-09-24 13:39:54 UTC
To reproduce:

1. deploy attached war to JBWS3516IT.war to server

2. start terminal 1 with nc -lk 7777

3. start terminal 2 with nc -lk 7778

4. start terminal 3, download file request_content.xml and run command 
curl -X POST -d @request_content.xml http://localhost:8080/JBWS3516IT/AnnotatedSecurityService

Response in terminal 2 (port 7778)

Response in terminal 1 (port 7777)

Repeat step 4 with request_content_oneway.xml, which gives expected results.

Comment 26 Petr Sakař 2013-09-24 13:41:12 UTC
Created attachment 802248 [details]
war with webservice using @Addressing throwing fault

Comment 27 Petr Sakař 2013-09-24 13:42:02 UTC
Created attachment 802249 [details]
request content

Comment 28 Petr Sakař 2013-09-24 13:43:01 UTC
Created attachment 802250 [details]
request content oneway

Comment 29 Petr Sakař 2013-09-24 13:50:53 UTC
Part of code to create war using Shrinkwrap

   static WebArchive creatDeployment() {
      WebArchive archive = ShrinkWrap.create(WebArchive.class, "JBWS3516IT.war")
            .setManifest(new StringAsset("Manifest-Version: 1.0\n"
                  + "Dependencies: org.jboss.ws.cxf.jbossws-cxf-client\n"))
      //archive.as(ZipExporter.class).exportTo(new File("/tmp", archive.getName()), true);
      return archive;

Comment 30 Petr Sakař 2013-09-24 13:52:56 UTC
Created attachment 802256 [details]
service interface java src

Comment 31 Petr Sakař 2013-09-24 13:53:31 UTC
Created attachment 802257 [details]
service implementation java src

Comment 32 Petr Sakař 2013-09-24 13:58:58 UTC
issue is present in EAP-6.1.1.ER7 (GA) as well

Comment 33 Petr Sakař 2013-09-26 19:00:08 UTC
Created attachment 803538 [details]

Comment 34 Jim Ma 2013-09-29 05:54:04 UTC
Request-response faultTo support requires
the "org.apache.cxf.ws.addressing.soap.DecoupledFaultHandler" interceptor, and jbossws-cxf doesn't add it to the bus
by default. So we have to add this interceptor with @Interceptors annotation like :
@InInterceptors(interceptors = { "org.apache.cxf.ws.addressing.soap.DecoupledFaultHandler" })

This can be also added implicitly in apache cxf's wsa addres implementation which I prefer to.  So after we upgraded to future cxf 2.7.8 release, we can
remove this annotated interceptor to ideally support this feature.

The test case I added to demonstrate how it works, please look at :http://anonsvn.jboss.org/repos/jbossws/stack/cxf/trunk/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf/jbws3516

Comment 39 Kyle Lape 2014-02-18 22:03:15 UTC
Making changes to make this BZ conform to standard product GSS BZ format

Comment 41 Petr Sakař 2014-04-01 14:34:48 UTC
Created attachment 881380 [details]
project with arquillian testcase

Comment 42 Petr Sakař 2014-04-01 14:35:24 UTC
verified for EAP 6.3.0.DR6

Comment 43 Rostislav Svoboda 2014-05-14 07:41:40 UTC
<jimma> rsvoboda, It should be public.

Fixing groups to include this in RN in Fixed Bugs section

Note You need to log in before you can comment on or make changes to this bug.