Uploaded image for project: '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
    • Status: Resolved
    • Priority: 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

      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.

        Gliffy Diagrams

          Attachments

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: