Invocation chain may run through Mediator copyInput after
DataTransformationInterceptor has already transformed data
--------------------------------------------------------------------------------------------------------------------
Key: TUSCANY-3832
URL: https://issues.apache.org/jira/browse/TUSCANY-3832
Project: Tuscany
Issue Type: Bug
Reporter: Scott Kurz
Priority: Minor
This is the problem I mentioned here:
http://markmail.org/message/yxq7w4aooawkiiog
I'm attaching a patch to reproduce this problem. First, I un-@Ignore(d) Simon
Laws' bare test in the implementation-sample extension module, (and fixed up
the logic a bit). Then, although we're still discussing how to simplify the
coding logic and naming in this area... I made my own simplification for now,
(to make this test pass), replacing "bare" with "notSubjectToWrapping".
If we stop right there.. I think there would still be some work to do... as
some binding-corba-runtime tests are now failing. Though I haven't looked
into why those tests are failing.. I'm taking a guess that it doesn't have to
do with the issue of this JIRA.
Included in the patch is a not-too-thought-out fix. My fix adds a header to
the Tuscany Message in the DataTransformInterceptor and looks for this header
in SCABindingInvoker in order to know whether or not to call Mediator.copyXXX.
Like I say in a comment in SCABindingInvoker:
// This relies on the fact that the response Message is actually the
same as the request Message. Is that a safe
// assumption???
At least this starts the discussion even if it's not complete.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
