The exception is actually reported via the bus, it's more a matter of whether the implementation type you are using surfaces the exception. For example, if you are using a bean service, an instance of ReferenceInvoker can be used to query any exception thrown during an in-only.
Support for robust in-only has been discussed is under consideration for a future release. If you have a use case other than what I outlined above, please let us know so that we can make sure it's taken into account.
1 of 1 people found this helpful
You might be interested in the following enhancement, which allows you to configure the visibility of faults/errors within in-only exchanges:
That will be in 2.0 for sure as Tomo has already submitted the pull request. The idea with this enhancement is that runtime errors which are not represented in the service contract still might be of interest to consumers, so we want to make the behavior configurable on a per-application basis. Robust-In-Only support is still a desirable feature in the future, which would allow the service contract to explicitly define an application-level fault.
Great to hear that. I hope that this exception propagation will be available also for service references, not only for reference invoker. Do you have any estimation when SY 2.0 will be released? You have made a great job with this project. It realy simplifies writing SOA applications.