[
https://issues.apache.org/jira/browse/TUSCANY-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-3832:
--------------------------------
Attachment: 3832.diff
> 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
> Attachments: 3832.diff
>
>
> 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
