[ https://issues.apache.org/jira/browse/TUSCANY-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Kurz resolved TUSCANY-3832. --------------------------------- Resolution: Fixed Assignee: Scott Kurz Fixed in 1070926 (and 1070928), enabling async bare test (in 1070929). Fixed by adding new isCompatibleWithoutUnwrapByValue method to InterfaceContractMapper. Changed logic in binding-sca-runtime so that if source/target operations do not have the same wrapper style, we do not do a mediator copyXXX, as we assume a DataTransformationInterceptor will be set up to do the transform. Also made a step towards simplifying wrapped vs. bare behavior and terminology by introducing "notSubjectToWrapping" as discussed on mailing list thread referenced in this JIRA. > 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 > Assignee: 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