Here are my additional observations. One could throw application level exception from the custom composer (of a RESTEasy reference binding), like it is done in rest-binding quickstarts:

if (clientResponse.getResponseStatus() == Response.Status.NOT_FOUND) {

                throw new ItemNotFoundException("Item not found");

}

But ItemNotFoundException will not propagate to the bean (invoking this reference) as such (and that's what I want).

RESTEasy OutboundHandler will not let any exception from your composer go further because of the following logic in handleMessage() method:

try {

            RESTEasyBindingData restResponse = methodInvoker.invoke(restRequest.getParameters(), restRequest.getHeaders());

            restResponse.setOperationName(opName);

            Message out = _messageComposer.compose(restResponse, exchange);

            // Our transformer magic transforms the entity appropriately here

            exchange.send(out);

} catch (Exception e) {

            final String m = RestEasyMessages.MESSAGES.unexpectedExceptionComposingRESTResponse();

            LOGGER.error(m, e);

            throw new HandlerException(m, e);

}

If your method's definition in Java interface of the composite reference contains exception declaration then your method will get HandlerException, otherwise you get java.lang.reflect.UndeclaredThrowableException.

So, in my Bean I could put try/catch and then handle HandlerException, where its cause will contain the exception thrown from the Composer, but that is ugly, imho.

There are ways to normalize native protocol messages to the SY message (which works for parameters) but why the same can't work for exceptions?

How can one build a business logic code (my Bean in this case) fully transparent from a communication protocol / binding (used either by composite service or composite reference) be it REST, plain HTTP, SOAP, sockets, whatever?

The only way I can think of right now is to develop an additional component between my bean and the composite reference, which will act as kind of a proxy handling HandlerException and translating it to the application exception. Though I don't like this solution....

Created JIRA: https://issues.jboss.org/browse/SWITCHYARD-2810

Please, check if all is right in there..

If it is a bug then I guess it is quite simple one.. do you have already an idea how it should be fixed (where sendFault() should be placed)? I am eager to patch my SY and try it again...

Should the decision (to send() or sendFault()) be based on the response status code? something like this? (stolen from HTTP component):

try {

            RESTEasyBindingData restResponse = methodInvoker.invoke(restRequest.getParameters(), restRequest.getHeaders());

            restResponse.setOperationName(opName);

            Message out = _messageComposer.compose(restResponse, exchange);

            // Our transformer magic transforms the entity appropriately here

            if (restResponse.getStatusCode() < 400) {

                exchange.send(out);

            } else {

                exchange.sendFault(out);

            }

} catch (Exception e) {

            final String m = RestEasyMessages.MESSAGES.unexpectedExceptionComposingRESTResponse();

            LOGGER.error(m, e);

            throw new HandlerException(m, e);

}

Hmm... but then it has nothing to do with the checked exceptions... I guess we need somehow to check the exception thrown from the composer..... (?)

I checked all available OutboundHandlers and one thing I can conclude is that any exception thrown from your Composer will result in HandlerException (and not in sendFault()). And thus it seems wrong to throw application exception from the composer because it won't be propagated as such. This is why I still question the use of ItemNotFoundException in rest-binding quickstarts.

If this thinking is right then in order to do sendFault() in the Handler one needs to play either with msg (as a result from the composer) or with the original response itself.. if so then it would mean that in the composer instead of throwing application exception you need to change/deal with the message (for example, when response status code is 404 and you want to indicate it as a fault to the business logic)..

Where is the trick? Anyone to clarify this issue?

Another general question: does sendFault() result in a thrown exception (declared on interface)?

Update: good reading on the internals regarding my last question: Re: Transaction behavior with faults/errors