You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Scott Kurz (JIRA)" <de...@tuscany.apache.org> on 2011/02/04 06:09:23 UTC
[jira] Created: (TUSCANY-3832) Invocation chain may run through
Mediator copyInput after DataTransformationInterceptor has already
transformed data
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
[jira] Updated: (TUSCANY-3832) Invocation chain may run through
Mediator copyInput after DataTransformationInterceptor has already
transformed data
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ 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
[jira] Closed: (TUSCANY-3832) Invocation chain may run through
Mediator copyInput after DataTransformationInterceptor has already
transformed data
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Kurz closed TUSCANY-3832.
-------------------------------
> 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
[jira] Resolved: (TUSCANY-3832) Invocation chain may run through
Mediator copyInput after DataTransformationInterceptor has already
transformed data
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ 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