[sleuth295] Exception Handling

[testark]

Hi @garyrussell. First of all, many thanks for taking the time to put up sleuth295 (it really, really helped me grasp the concept). 👍 for that!

I have a question though... Let's imagine that SomeServiceImpl made some validations and threw an IllegalArgumentException (or some other custom RuntimeException). How can this or any other exception be sent as a reply back to Client, so that it can not only receive a valid return value but also handle exceptions with a standard catch clause?

[garyrussell]

Hi @testark I am glad you "found" it - I meant to put a link to it on spring-cloud/spring-cloud-sleuth#295

Yes, to reproduce the exception propagation that is handled by remoting needs a little more work.

I just pushed another commit to show the technique - hopefully it's self-explanatory.

FYI, I will be traveling for the next couple of weeks and likely won't be online much, if at all.

/cc @artembilan

[artembilan]

For the record the question has begun from here: http://stackoverflow.com/questions/37689582/spring-boot-spring-integration-amqp

[testark]

@garyrussell @artembilan thank you very much to both of you, really :-) It was @artembilan that gave me the link. This was a life saver, so many many thanks indeed 👍

[testark]

@garyrussell @artembilan if you don't mind, I'd just like to ask one final question. How do I plug-in the bundled Kryo codec so that messages are Kryo-serialized instead of Java-serialized?

[garyrussell]

@testark The message conversion is actually done by Spring AMPQ, not Spring Integration; it doesn't currently have a kryo implementation (only Java and Json).

Spring Integration does, however, provide transformer implementations (PayloadEncodingTransformer, DecodingTransformer) which can be configured as a @Bean with a Kryo codec.

Then, all you need to do is add a .transform(transformer()) on each side, before/after the Amqp gateway in the integration flow, where transformer() is the appropriate transformer bean.

The Spring AMQP "conversion" then becomes a pass-through because the payload is already a byte[].

[artembilan]

Note. Since EncodingPayloadTransformer (as well as DecodingTransformer) has only one constructor option, there is no need to declare it as a @Bean.
You can just do:

.transform(new EncodingPayloadTransformer(kryoCode()))
...
.transform(new DecodingTransformer(kryoCode(), Foo.class))

and Java DSL will take care about bean for you.
Just less boilerplate code! 😄

I have just raised https://github.com/spring-projects/spring-integration-java-dsl/issues/86 to make it more straightforward in the SI Java DSL.

[testark]

@garyrussell @artembilan thank you very much for all your support, really! It has been a life saver 👍