Effective October 27, 2012, online and email support for FuseSource products will move to Red Hat support channels. For more information, please see the JIRA Migration to Red Hat FAQ.
As of October 27th, please open all new issues in the Red Hat Customer Portal .
Issue Details (XML | Word | Printable)

Key: SF-283
Type: Bug Bug
Status: Resolved Resolved
Resolution: Resolved at Apache
Priority: Critical Critical
Assignee: Freeman Fang
Reporter: Joe Luo
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
FUSE Services Framework

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

Created: 10/Sep/10 08:33 AM   Updated: 13/Sep/10 06:35 AM
Component/s: None
Affects Version/s: 2.2.9-fuse-01-00
Fix Version/s: 2.2.10-fuse-00-00

External Issue URL: https://issues.apache.org/jira/browse/CXF-2990


 Description  « Hide
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.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Freeman Fang made changes - 10/Sep/10 08:34 AM
Field Original Value New Value
Assignee Freeman Fang [ ffang ]
Joe Luo made changes - 10/Sep/10 08:42 AM
Link This issue fixes DEV-2607 [ DEV-2607 ]
Freeman Fang made changes - 13/Sep/10 05:27 AM
Freeman Fang made changes - 13/Sep/10 06:35 AM
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s 2.2.10-fuse-00-00 [ 10970 ]
Resolution Resolved at Apache [ 6 ]