My "solution" is probably premature as it breaks the unit tests...but I still
need to know if I'm on the right lines and there is a bug here, or if I'm
just using the jbi component in a way it's not intended to be used.

I've attached a simple test case (
http://servicemix.396122.n5.nabble.com/file/n3219106/TestCase-JBIFault.zip
TestCase-JBIFault.zip ) that shows the type of thing I'm hoping to be able
to do.  It's no more than just being able to handle an exception that was
thrown from an in-out jbi route:

        from("direct:test")
            .doTry()
                .to("log:Starting JBI Test")
                .to("jbi:endpoint:urn:testcase:testing?mep=in-out")
            .doCatch(SerialException.class)
                .to("log:Caught Serial exception")
            .end();

        from("jbi:endpoint:urn:testcase:testing?mep=in-out")
            .errorHandler(noErrorHandler())
            .to("log:about to throw exception?level=ERROR")
            .throwException(new SerialException("Test"));

Thanks,
Steve.


slew wrote:
> 
> Hi,
> 
> Looking further into this.  I can see that in
> org.apache.servicemix.camel.CamelProviderEndpoint onFailure, the camel
> exchange details are copied to the MessageExchange, but the exception is
> not.
> 
> If I explicitely copy the camel exception to the MessageExchange as in
> bold below, then the exception navigates the JBI NMR.
> 
> public void onFailure(Exchange exchange) {
>         MessageExchange me = JbiBinding.getMessageExchange(exchange);
>         try {
>             if (exchange.hasOut()) {
>                 Fault fault = me.createFault();
>                 me.setError(binding.extractException(exchange));
>                 binding.copyFromCamelToJbi(exchange.getOut(), fault);
>                 if (isFaultCapable(me)) {
>                     me.setFault(fault);
>                     doSend(me);
>                 } else {
>                     // MessageExchange is not capable of conveying faults
> -- sending the information as an error instead
>                     fail(me, new FaultException("Fault occured for " +
> exchange.getPattern() + " exchange", me, fault));
>                 }
>             } else {
>                 fail(me, binding.extractException(exchange));
>             }
>         } catch (MessagingException e) {
>             logger.warn("Unable to send JBI MessageExchange after
> successful Camel route invocation: " + me, e);
>         } 
>     }
> 
> Please could someone with more experience than me comment on whether there
> is anything wrong with this approach and whether it makes sense to raise a
> JIRA?
> 
> Thanks for looking,
> Steve.
> 
> 
> slew wrote:
>> 
>> Hi,
>> 
>> I'm using camel 2.3 within smx 3.3.2.
>> 
>> The main camel route implements a routing slip.  The steps in the routing
>> slip are made up from other jbi service assemblies, for example that do
>> things like custom validation, auditing.  The idea being that new jbi
>> components can be deployed to smx then configured in the routing slip at
>> runtime to modify behaviour.
>> 
>> My first implementation used the vm component to communicate between the
>> different camel contexts, but I was advised that this is not the correct
>> way to do things and I should use camel's jbi component - which makes
>> sense and was obvious once pointed out.
>> 
>> The thing I'm not sure about is how best/correctly to propagate
>> exceptions.  When using the vm components, exceptions could be thrown in
>> one route and caught in another, but this isn't the same for jbi as the
>> exchange goes through the NMR.
>> 
>> I've tried throwing an exception from the camel route with and without
>> the convertException option set, but although the route is marked as a
>> fault and I get a FaultException in the CamelExceptionCaught property, I
>> lose the details of the exception.
>> 
>> The other option I tried was setFaultBody and converting the exception to
>> and from xml.
>> 
>> What I'd like to know is what the recommended way to do this, so I don't
>> end up implementing a long winded approach when there's a better
>> alternative I just can't see.
>> 
>> Thanks for any help,
>> Steve.
>> 
> 
> 

-- 
View this message in context: 
http://servicemix.396122.n5.nabble.com/JBI-Exception-Propagation-Advice-tp3211854p3219106.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.

Reply via email to