On Tue, Jun 30, 2009 at 2:38 PM, Scott Kurz<[email protected]> wrote: > 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?
I wanted to highlight that we were fluffing up this structure to support unchecked exceptions in this specific case and that it didn't have anything to do with SOAP specifically. The rest of the messages passing are not in the http://schemas.xmlsoap.org/soap/envelope/ namespace. I looked at the kind of structure you get for a checked exception and went with something similar. If the consensus is to use the SOAP structure I don't have a problem. > > 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). Fair enough. > > Thanks, > Scott >
