Raymond, Thanks for giving this some thought.
Yeah, it might be worth adding the input/outputs as well to a factored-out util as well. I guess you could put the Message body handling (e.g. setBody or setFaultBody) into a common util as well, but I wasn't pushing that. As I'm looking this over I'm noticing how we rely on the intf introspectors to set the IDL_INPUT but set the IDL_OUTPUT ourselves here. Maybe it doesn't matter (unless we want to refactor), but wondering if there was a reason for the asymmetry there. Not sure if any of the transformers actually use the 'wire' in the 'metadata'.. if they don't might be better to cut out of a util. Scott On Wed, Jul 23, 2008 at 1:22 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > It's ok to refactor the code out. Would it be better to extract the > transformation logic for the payload (input/output/fault) out > of DataTransformationInterceptor to become OperationDataTransformer (or a > better name) and expose it as a utility service? This way, binding or > implementation providers can use it to transform input, output and fault > data. > > Thanks, > Raymond > > *From:* Scott Kurz <[EMAIL PROTECTED]> > *Sent:* Tuesday, July 22, 2008 11:41 AM > *To:* [email protected] > *Subject:* refactor fault matching in DataTransformationInterceptor for > non-interceptor usage > > In experimenting with using the Mediator from a binding impl, rather than > only via the DataTransformationInterceptor on the wire, I found myself > needing to use the exact same logic (that the > DataTransformationInterceptor uses) to map an Message's fault body to both > the source/target fault DataType. > > I coded up a refactoring of the fault matching function and added it to a > sandbox: > > https://svn.apache.org/repos/asf/tuscany/sandbox/scottkurz/core-databinding > > I'd be interested to hear any comments. (I got the 1.3 itests to pass > with my change though I have some JDK issues and can't get HEAD to build) > > Thanks, > Scott > >
