Intercepting service invocations

[objectiser]

I have an exchange handler that evaluates an exchange against some business policy, and if relevant prevents the invocation from occuring.

Currently this handler just throws a SwitchyardException - but this appears to be returned back to the initial binding - so this bypasses any response handling in the intervening services.

My preference would be to return a message - however not sure whether doing this on the exchange would prevent the exchange from continuing to the next binding/implementation?

When I tried this, I got:

12:38:01,964 ERROR [org.apache.camel.processor.DefaultErrorHandler] (http--127.0.0.1-8080-1) Failed delivery for (MessageId: ID-gbrown-redhat-56846-1348141074272-0-16 on ExchangeId: ID-gbrown-redhat-56846-1348141074272-0-17). Exhausted after delivery attempt: 1 caught: java.lang.NullPointerException: java.lang.NullPointerException

    at org.switchyard.handlers.TransformHandler.initOutTransformSequence(TransformHandler.java:135) [switchyard-runtime-0.6.0-SNAPSHOT.jar:0.6.0-SNAPSHOT]

    at org.switchyard.handlers.TransformHandler.handleMessage(TransformHandler.java:88) [switchyard-runtime-0.6.0-SNAPSHOT.jar:0.6.0-SNAPSHOT]

    at org.switchyard.bus.camel.HandlerProcessor.process(CamelExchangeBus.java:204)

    at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61) [camel-core-2.10.0.jar:2.10.0]

    at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73) [camel-core-2.10.0.jar:2.10.0]

    at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99) [camel-core-2.10.0.jar:2.10.0]

when returning a message in the exchange handler (e.g. exchange.send(mesg) ).

Just wondering whether this is a use case that has been considered? Or are the exchange handlers not expected to block invocations?

Regards

Gary

[kcbabo]

ExchangeHandler instances can definitely block/intervene in the processing of a message.  Check out the policy handler for an example - if policy requirements are not met, the handler rejects the exchange.

In the case of an error, replying with a fault is appropriate.  You can do this via sendFault() or by throwing a HandlerException.

In the case of a normal reply (e.g. a cache), you should call send to reply.

Sounds like there may be a bug based on the stack trace above.  If you can submit a test case or app that reproduces the behavior that would be great.

[objectiser]

Looks like the master no longer has this problem - the correct fault string is now passed to the SOAP client.