FUSE Services Framework
  1. FUSE Services Framework
  2. SF-283

Response Context should not be empty even with a SOAP fault message

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Critical Critical
    • Resolution: Resolved at Apache
    • Affects Version/s: 2.2.9-fuse-01-00
    • Fix Version/s: 2.2.10-fuse-00-00
    • Component/s: None
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      I'm using an asynchronous JAX-WS Dispatch based CXF client. This client gets a SOAP fault back. The code looks like:

      Dispatch<SOAPMessage> dispatch = service.createDispatch(portName, SOAPMessage.class, Service.Mode.MESSAGE);
      dispatch.invokeAsync(message, handler);
      

      and the Handler class:

      ... implements AsyncHandler<SOAPMessage> {
          ...
          public void handleResponse(Response<SOAPMessage> response) {
      
              try {
                  response.get();
                  // do nothing if no soap fault is present
              } catch (Exception e) {
                  e.printStackTrace();
                 // TODO need to access SOAP headers returned with the SOAP fault
                 // through response context 
              } 
          }
      }
      

      Inside the catch block I need to investigate SOAP headers returned with the SOAP fault. Normally, response context should provide a mean to acces SOAP header. However, it looks like that the response.getContext() always return an empty map if a SOAP fault message was received.

      Looking into it further, the processResult(...) method of ClientImpl class has following code snippet:

            // Check to see if there is a Fault from the outgoing chain
              Exception ex = message.getContent(Exception.class);
              boolean mepCompleteCalled = false;
              if (ex != null) {
                  getConduitSelector().complete(exchange);
                  mepCompleteCalled = true;
                  if (message.getContent(Exception.class) != null) {
                      throw ex;
                  }
              }
              ex = message.getExchange().get(Exception.class);
              if (ex != null) {
                  if (!mepCompleteCalled) {
                      getConduitSelector().complete(exchange);
                  }
                  throw ex;
              }
      
              // Wait for a response if we need to
              if (oi != null && !oi.getOperationInfo().isOneWay()) {
                  synchronized (exchange) {
                      waitResponse(exchange);
                  }
              }
      
              // leave the input stream open for the caller
              Boolean keepConduitAlive = (Boolean)exchange.get(Client.KEEP_CONDUIT_ALIVE);
              if (keepConduitAlive == null || !keepConduitAlive) {
                  getConduitSelector().complete(exchange);
              }
      
              // Grab the response objects if there are any
              List resList = null;
              Message inMsg = exchange.getInMessage();
              if (inMsg != null) {
                  if (null != resContext) {
                      resContext.putAll(inMsg);
                      if (LOG.isLoggable(Level.FINE)) {
                          LOG.fine("set responseContext to be" + resContext);
                      }
                  }
                  resList = inMsg.getContent(List.class);
              }
      
              // check for an incoming fault
              ex = getException(exchange);
      
              if (ex != null) {
                  throw ex;
              }
      
              if (resList != null) {
                  return resList.toArray();
              }
      
              return null;
      

      You can see that an exception is thrown before the empty response context could get chance to be populated in case a SOAP fault message is received. Thus, it is impossible to access the SOAP headers and other information through response context. And if a proper SOAP message without any fault is returned, the response context will be populated to provide access to SOAP headers and other data.

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Freeman(Yue) Fang
            Reporter:
            Joe Luo
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: