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/07/06 15:57:16 UTC
[jira] [Created] (TUSCANY-3894) Binding.sca local behavior: copy
vs. mediate, same-databinding assumption
Binding.sca local behavior: copy vs. mediate, same-databinding assumption
--------------------------------------------------------------------------
Key: TUSCANY-3894
URL: https://issues.apache.org/jira/browse/TUSCANY-3894
Project: Tuscany
Issue Type: Improvement
Components: SCA Java Runtime
Reporter: Scott Kurz
Assignee: Scott Kurz
Priority: Minor
As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884
the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation.
Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either.
Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (TUSCANY-3894) Binding.sca local behavior:
copy vs. mediate, same-databinding assumption
Posted by Scott Kurz <sk...@gmail.com>.
Raymond,
I'm glad you asked ;)
This is local as in "same-JVM", but we still have paths through this
code with remotable interfaces that need the PBV semantics.
Before my TUSCANY-3894 code, we simply used Mediator.copyXXX. The
solution only worked if client & service both used the same
databinding.
Since this would probably be the case most of the time... I didn't
want to argue too strongly that we must switch to the WSDL/XML binding
in case the consensus was that this was a useful thing to optimize
for... but I do think we need the ability to plugin the XML/WSDL
support easily. I also didn't want to repeat the PBR calculation
which is embedded within the local binding.
Re: [jira] [Commented] (TUSCANY-3894) Binding.sca local behavior: copy vs. mediate, same-databinding assumption
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Thanks for sending out the note.
In addition to the concern that I raised against your commit log, can you explain why we need to do transformation for local sca binding? I assume that's for distributed sca binding.
Raymond Feng
Sent from my iPhone
On Jul 27, 2011, at 7:51 PM, "Scott Kurz (JIRA)" <de...@tuscany.apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072148#comment-13072148 ]
>
> Scott Kurz commented on TUSCANY-3894:
> -------------------------------------
>
> I checked in some more changes here, so let me explain.
>
> From the runtime side, in r1151632, I refactored the local part of sca-binding-runtime so that the exact details of the data transform are extensible.
> I'm creating a new interface, BindingSCATransformer which I'll implement to handle the transform details.
>
> My thought is that the base portion of the binding will do things like calculate whether to do the pass-by-reference optimization and establish other aspects of the invoker/interceptor chain. This will be handled in DefaultLocalSCAReferenceBindingProvider, which will also compute the WSDL contract, in case the transform needs it, as well as return the ComponentTypeRefIC to disable the DataTransformationInterceptor. So we're always initiating data transform from the binding, not via DataTransformationInterceptor on the wire, just to reiterate.
>
> In my scheme, the BindingProviderFactory impl will create a ref binding provider which will potentially extend the base DefaultLocalSCAReferenceBindingProvider by providing its own BindingSCATransformer (and possibly a different databinding then the DOM default one I'm using).
>
> There are now two provider factories, each resulting in a different BindingSCATransformer being used.
>
> The first, the default, maintains the current behavior we're used to. Notably, it:
> - uses Mediator.copyXXX rather than Mediator.mediateXXX, which notably does not use the JAX-WS wrappers
> - has RMI-like referential integrity for parameters (see earlier comments)
> - for POJOs, preferes Java serialization (if java.io.Serializable), then JAXB/XML serialization
>
> The second is an XML-centric databinding. Some notes:
> - It's built via pointing to XMLWFLocalSCABindingProviderFactory in the extension point, which builds the XMLWFBindingSCATransformer.
> - relies on building a WSDL InterfaceContract to be used along with Mediator.mediateXXX
> - uses a DOM databinding (since there's been a move to avoid AXIOM if possible), but this could easily be switched in another impl with little code
> - The XMLWFLocalSCAReferenceBindingProvider actually extends the DefaultLocalSCAReferenceBindingProvider, the provider in the first, default impl.
>
> I would like to add a weighting to the various binding provider factories, and ideally polish things up a bit. However, there are a couple more JIRAs I need to open after noticing some side effects, and it seemed easiest to have something concrete in the trunk to refer to.
>
> So by committing this code I have:
> - enabled the use of separate databindings across client/service
> - allowed extension with reuse of the PBR calculation.
>
> Scott
>
>> Binding.sca local behavior: copy vs. mediate, same-databinding assumption
>> --------------------------------------------------------------------------
>>
>> Key: TUSCANY-3894
>> URL: https://issues.apache.org/jira/browse/TUSCANY-3894
>> Project: Tuscany
>> Issue Type: Improvement
>> Components: SCA Java Runtime
>> Affects Versions: Java-SCA-2.x
>> Reporter: Scott Kurz
>> Assignee: Scott Kurz
>> Priority: Minor
>> Fix For: Java-SCA-2.0
>>
>> Attachments: 3894.patch, 3894.tests.patch
>>
>>
>> As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884
>> the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation.
>> Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either.
>> Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate.
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
[jira] [Commented] (TUSCANY-3894) Binding.sca local behavior: copy
vs. mediate, same-databinding assumption
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072148#comment-13072148 ]
Scott Kurz commented on TUSCANY-3894:
-------------------------------------
I checked in some more changes here, so let me explain.
>From the runtime side, in r1151632, I refactored the local part of sca-binding-runtime so that the exact details of the data transform are extensible.
I'm creating a new interface, BindingSCATransformer which I'll implement to handle the transform details.
My thought is that the base portion of the binding will do things like calculate whether to do the pass-by-reference optimization and establish other aspects of the invoker/interceptor chain. This will be handled in DefaultLocalSCAReferenceBindingProvider, which will also compute the WSDL contract, in case the transform needs it, as well as return the ComponentTypeRefIC to disable the DataTransformationInterceptor. So we're always initiating data transform from the binding, not via DataTransformationInterceptor on the wire, just to reiterate.
In my scheme, the BindingProviderFactory impl will create a ref binding provider which will potentially extend the base DefaultLocalSCAReferenceBindingProvider by providing its own BindingSCATransformer (and possibly a different databinding then the DOM default one I'm using).
There are now two provider factories, each resulting in a different BindingSCATransformer being used.
The first, the default, maintains the current behavior we're used to. Notably, it:
- uses Mediator.copyXXX rather than Mediator.mediateXXX, which notably does not use the JAX-WS wrappers
- has RMI-like referential integrity for parameters (see earlier comments)
- for POJOs, preferes Java serialization (if java.io.Serializable), then JAXB/XML serialization
The second is an XML-centric databinding. Some notes:
- It's built via pointing to XMLWFLocalSCABindingProviderFactory in the extension point, which builds the XMLWFBindingSCATransformer.
- relies on building a WSDL InterfaceContract to be used along with Mediator.mediateXXX
- uses a DOM databinding (since there's been a move to avoid AXIOM if possible), but this could easily be switched in another impl with little code
- The XMLWFLocalSCAReferenceBindingProvider actually extends the DefaultLocalSCAReferenceBindingProvider, the provider in the first, default impl.
I would like to add a weighting to the various binding provider factories, and ideally polish things up a bit. However, there are a couple more JIRAs I need to open after noticing some side effects, and it seemed easiest to have something concrete in the trunk to refer to.
So by committing this code I have:
- enabled the use of separate databindings across client/service
- allowed extension with reuse of the PBR calculation.
Scott
> Binding.sca local behavior: copy vs. mediate, same-databinding assumption
> --------------------------------------------------------------------------
>
> Key: TUSCANY-3894
> URL: https://issues.apache.org/jira/browse/TUSCANY-3894
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-2.x
> Reporter: Scott Kurz
> Assignee: Scott Kurz
> Priority: Minor
> Fix For: Java-SCA-2.0
>
> Attachments: 3894.patch, 3894.tests.patch
>
>
> As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884
> the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation.
> Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either.
> Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TUSCANY-3894) Binding.sca local behavior: copy
vs. mediate, same-databinding assumption
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Kurz resolved TUSCANY-3894.
---------------------------------
Resolution: Fixed
Resolved by having local binding.sca reference provider do the following:
- look at source/target operations and see if for each inputs/output, the source and target DataType are using the same databinding.
- If so, set up the SameDBCopyTransformer which uses Mediator.copyXXX to do the data transform (for PBV cases)
- Else, use the WSDLMediateTransformer, calculating a wsdlOperation and doing a Mediator.mediateXXX from sourceOp->wsdlOp, and then one from wsdlOp-> targetOp
> Binding.sca local behavior: copy vs. mediate, same-databinding assumption
> --------------------------------------------------------------------------
>
> Key: TUSCANY-3894
> URL: https://issues.apache.org/jira/browse/TUSCANY-3894
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-2.x
> Reporter: Scott Kurz
> Assignee: Scott Kurz
> Priority: Minor
> Fix For: Java-SCA-2.0
>
> Attachments: 3894.patch, 3894.tests.patch
>
>
> As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884
> the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation.
> Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either.
> Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TUSCANY-3894) Binding.sca local behavior: copy
vs. mediate, same-databinding assumption
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Kurz resolved TUSCANY-3894.
---------------------------------
Resolution: Fixed
> Binding.sca local behavior: copy vs. mediate, same-databinding assumption
> --------------------------------------------------------------------------
>
> Key: TUSCANY-3894
> URL: https://issues.apache.org/jira/browse/TUSCANY-3894
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-2.x
> Reporter: Scott Kurz
> Assignee: Scott Kurz
> Priority: Minor
> Fix For: Java-SCA-2.0
>
> Attachments: 3894.patch, 3894.tests.patch
>
>
> As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884
> the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation.
> Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either.
> Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3894) Binding.sca local behavior: copy
vs. mediate, same-databinding assumption
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063268#comment-13063268 ]
Simon Laws commented on TUSCANY-3894:
-------------------------------------
Object identity
===========
So, IIUC, you're saying the the following is true for the SCA binding delegations
local p1==p2
remote(ws) p1!=p2
remote(rmi) p1==p2
Is that correct? If so I think what you say is correct in that there is a binding/technology specific aspect to be taken into account. I.e. we're not in the business of making web services behave like RMI. We take them as they come.
Databinding
=========
Still not sure I get this. In the local case I think there will only be on databinding transformation, if any is required, as the local wire optimizes the service side databinding interceptor away. I might just try a test where the reference has a Java interface and the service implementation has a WSDL interface., e.g. BPEL. Thinking about this we need to test that there isn't a hole if you specify a service interface, as opposed to a component type service interface, with the intention of restricting the number of operations exposed.
> Binding.sca local behavior: copy vs. mediate, same-databinding assumption
> --------------------------------------------------------------------------
>
> Key: TUSCANY-3894
> URL: https://issues.apache.org/jira/browse/TUSCANY-3894
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-2.x
> Reporter: Scott Kurz
> Assignee: Scott Kurz
> Priority: Minor
>
> As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884
> the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation.
> Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either.
> Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-3894) Binding.sca local behavior: copy
vs. mediate, same-databinding assumption
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Kurz updated TUSCANY-3894:
--------------------------------
Affects Version/s: Java-SCA-2.x
> Binding.sca local behavior: copy vs. mediate, same-databinding assumption
> --------------------------------------------------------------------------
>
> Key: TUSCANY-3894
> URL: https://issues.apache.org/jira/browse/TUSCANY-3894
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-2.x
> Reporter: Scott Kurz
> Assignee: Scott Kurz
> Priority: Minor
>
> As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884
> the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation.
> Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either.
> Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3894) Binding.sca local behavior: copy
vs. mediate, same-databinding assumption
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061378#comment-13061378 ]
Scott Kurz commented on TUSCANY-3894:
-------------------------------------
I gave what I called the "object reference graph" issue a bit more thought. I'm sorry if this discussion is rediscovering the wheel since I'm sure I could search and read that it's already been well-understood (on this list even???), but here goes my rehash:
Let me use an example:
If I have: public void m1(Person p1, Person p2) and if I do:
Person p = ...
ref.m1(p,p);
then I'm asking is the object identity on the client side preserved on the service side, i.e. does p1==p2?
I was concerned because for the binding-ws-axis2 impl, the answer is definitely "no", and it seemed nice to have this local default binding impl behave in the same way as the interoperable WS binding. It's different because with MediatorImpl.copyInput(...) and the use of IdentityHashMap, p1==p2 is "true".
However, for our own binding-rmi, object identity is preserved. So I guess you could say it's just a question of whether you want the binding to be more Java-centric (RMI-like) or XML-centric (WS-like), and I guess precedence would argue to leave things alone all other things being equal.
That means the only open issue is are we OK with the single-databinding requirement or should we add the ability to leverage the DataTransformationInterceptor? (With the delegation potentially added by TUSCANY-3884, we could have both and then the question is which should the default be)?
Circling back to the object identity thing.... if a switch to use the DTI with XML-centric copy as the default changed the object identity story, then, I'd think this wouldn't be a huge deal, coming before a final 2.0 release especially.
Any thoughts?
> Binding.sca local behavior: copy vs. mediate, same-databinding assumption
> --------------------------------------------------------------------------
>
> Key: TUSCANY-3894
> URL: https://issues.apache.org/jira/browse/TUSCANY-3894
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-2.x
> Reporter: Scott Kurz
> Assignee: Scott Kurz
> Priority: Minor
>
> As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884
> the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation.
> Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either.
> Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TUSCANY-3894) Binding.sca local behavior: copy
vs. mediate, same-databinding assumption
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Kurz reopened TUSCANY-3894:
---------------------------------
I never actually used the structure I built as part of this work to fix the original problem, as shown in some of the data-copy tests @Ignore(d) currently.
Would like to complete by fixing this.
> Binding.sca local behavior: copy vs. mediate, same-databinding assumption
> --------------------------------------------------------------------------
>
> Key: TUSCANY-3894
> URL: https://issues.apache.org/jira/browse/TUSCANY-3894
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-2.x
> Reporter: Scott Kurz
> Assignee: Scott Kurz
> Priority: Minor
> Fix For: Java-SCA-2.0
>
> Attachments: 3894.patch, 3894.tests.patch
>
>
> As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884
> the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation.
> Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either.
> Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-3894) Binding.sca local behavior: copy
vs. mediate, same-databinding assumption
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Kurz updated TUSCANY-3894:
--------------------------------
Attachment: 3894.tests.patch
Some tests showing a couple of the issues I raised, e.g.
1) The fact that the copy works like binding.rmi in preserving referential integrity, unlike binding.ws
2) The problem of doing a copy when different databindings are involved (see testJSONSCA())
> Binding.sca local behavior: copy vs. mediate, same-databinding assumption
> --------------------------------------------------------------------------
>
> Key: TUSCANY-3894
> URL: https://issues.apache.org/jira/browse/TUSCANY-3894
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-2.x
> Reporter: Scott Kurz
> Assignee: Scott Kurz
> Priority: Minor
> Fix For: Java-SCA-2.0
>
> Attachments: 3894.tests.patch
>
>
> As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884
> the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation.
> Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either.
> Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-3894) Binding.sca local behavior: copy
vs. mediate, same-databinding assumption
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Laws updated TUSCANY-3894:
--------------------------------
Fix Version/s: Java-SCA-2.0
Moving to 2.0 as this is related to all of the other binding.sca stuff that we're trying to sort out.
> Binding.sca local behavior: copy vs. mediate, same-databinding assumption
> --------------------------------------------------------------------------
>
> Key: TUSCANY-3894
> URL: https://issues.apache.org/jira/browse/TUSCANY-3894
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-2.x
> Reporter: Scott Kurz
> Assignee: Scott Kurz
> Priority: Minor
> Fix For: Java-SCA-2.0
>
>
> As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884
> the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation.
> Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either.
> Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-3894) Binding.sca local behavior: copy
vs. mediate, same-databinding assumption
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Kurz updated TUSCANY-3894:
--------------------------------
Attachment: 3894.patch
Here is a patch which only does the copy in the binding if it detects that the DataTransformationInterceptor will NOT be established on the wire.
It may leave some things to be desired...
For one, what if the Mediator-invoked transformer(s) somehow don't result in a copy being made (is this even possible?) Then we wouldn't get the PBV semantics. That said, I can't think of such a case today for existing transformers. Also note that BaseDataBinding.copy just returns its input (i.e. does NOT do a copy), so we could have such a hole in theory..but probably not in practice..today.
Also, it might be nicer to do the "isPBV" and "isTransformationRequired" in a single place, or somehow unify the two calculations so we don't have to call "isTransformationRequired" twice, but I can't think of a better way right now.
Finally, I know we've been trying to be careful about declaring cross-module SPIs wrt the OSGi runtime, so not sure if anyone would object to now exporting a new package:
org.apache.tuscany.sca.core.databinding.wire
> Binding.sca local behavior: copy vs. mediate, same-databinding assumption
> --------------------------------------------------------------------------
>
> Key: TUSCANY-3894
> URL: https://issues.apache.org/jira/browse/TUSCANY-3894
> Project: Tuscany
> Issue Type: Improvement
> Components: SCA Java Runtime
> Affects Versions: Java-SCA-2.x
> Reporter: Scott Kurz
> Assignee: Scott Kurz
> Priority: Minor
> Fix For: Java-SCA-2.0
>
> Attachments: 3894.patch, 3894.tests.patch
>
>
> As discussed in: https://issues.apache.org/jira/browse/TUSCANY-3884
> the binding-sca-runtime code seems to assume that the reference/service sides share a common databinding, which might not be a desirable limitation.
> Also the object reference graph of copy vs. mediate seems to be different, which might not be preferable either.
> Just working on some tests now before commenting further, however I wanted to open this up to move the discussion out of the 3884 JIRA, to avoid confusion as this is a separate issue from simply adding the ability to delegate.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira