Simon, Thanks for picking this up again.
>From the service-side perspective, this is a step towards enabling a non-Tuscany client to consume our "unchecked exc" JMS Message. In my mind the SOAP fault format was a bigger step towards this goal, but how much bigger? Is SOAP fault more "standardized" on paper without enabling a single real-world client to consume this Message regardless? I don't have the experience to say.... so I'd be OK with either. I'm curious, did you have a reason for preferring your format over the SOAP fault? >From the reference-side, there's no reason to expect this a non-Tuscany JMS Message sender on the other side would ever produce a Message in this format, so I think it's correct to only add this behavior after checking for the Tuscany "fault" user prop. One note code structure-wise... I think it would be clearer if we continued to use the JMSMessageProcessor.createFaultMessage(), etc., to do this type of thing... i.e., keep it one place rather than adding logic to the service interceptor as well (like your patch does, though I know that's only a patch). Thanks, Scott
