Bug 900634 (JBPAPP6-871)

Link: Added: This issue relates to JBWS-3516

Can we get a component update for this?

Link: Added: This issue is a dependency of JBPAPP-9438

RemoteIssueLink: Added: This issue links to "CXF-4382 (Web Link)"

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:
{noformat}
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
        <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>
</soap:Header>
<soap:Body>
  <ns:sayHelloWorldFrom xmlns:ns="http://test/">
    <arg0>woo</arg0>
  </ns:sayHelloWorldFrom>
</soap:Body>
</soap:Envelope>
{noformat}

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: 

{noformat}
[jmartisk@dhcp-4-145 ~]$ nc -lk 7778
POST / HTTP/1.1
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>
{noformat}

For Oneway operations (similar issue - JBPAPP-9464) this works for me, but for two-way operations, it doesn't. Am I doing something wrong?

Release Notes Docs Status: Added: Not Yet Documented

Release Notes Docs Status: Removed: Not Yet Documented 
Docs QE Status: Removed: NEW 

Did you get some thing from port 7777 the faultTo port ? 

No, nothing arrived there.

Tried with 6.0.1.GA. Issue still present.

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 ?

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.

{noformat}
@WebService
@Addressing(enabled = true)
public class SimpleWebService { 
   @WebMethod
   public void throwFault() throws Exception {
      throw new Exception("This is a fatal error.");
   }
}
{noformat}

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.

Hi Jan, Sorry for the wrong link. I meant this one : https://svn.jboss.org/repos/jbossws/thirdparty/cxf/tags/cxf-2.4.9.jbossorg-1/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/addr_feature/WSAFaultToClientServerTest.java

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.

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);

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..

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.  

This is already fixed in EAP 6.1.1, and we can verify it in EAP 6.2.

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.

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


Expected:
Response in terminal 2 (port 7778)

Actual:
Response in terminal 1 (port 7777)

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

Created attachment 802248 [details]
war with webservice using @Addressing throwing fault

Created attachment 802249 [details]
request content

Created attachment 802250 [details]
request content oneway

Part of code to create war using Shrinkwrap

   @Deployment
   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"))
            .addClass(org.jboss.qa.management.ws.cli.AnnotatedServiceIface.class)
            .addClass(org.jboss.qa.management.ws.cli.AnnotatedServiceThrowFaultImpl.class);
      //archive.as(ZipExporter.class).exportTo(new File("/tmp", archive.getName()), true);
      return archive;
   }

Created attachment 802256 [details]
service interface java src

Created attachment 802257 [details]
service implementation java src

issue is present in EAP-6.1.1.ER7 (GA) as well

Created attachment 803538 [details]
TestCase

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

Making changes to make this BZ conform to standard product GSS BZ format

Created attachment 881380 [details]
project with arquillian testcase

verified for EAP 6.3.0.DR6

<jimma> rsvoboda, It should be public.

Fixing groups to include this in RN in Fixed Bugs section