2 Replies Latest reply on Sep 25, 2012 9:38 AM by Gary Brown

    Intercepting service invocations

    Gary Brown Master

      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

        • 1. Re: Intercepting service invocations
          Keith Babo Master

          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.

          • 2. Re: Intercepting service invocations
            Gary Brown Master

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