You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2009/11/17 15:44:36 UTC
[2.x] Assembly otest regression
I get a few new failures in the assembly otests now. For example,
ASM_4001 which fails with...
Service fault received - detail: Test service got an exception during
execution: org.apache.tuscany.sca.databinding.TransformationException
No wrapper handler is provided for databinding: null
It seems to be being throw on the wire between the test client and the
first test component. This is wired with binding.sca. The target
service in this case has a WSDL interface. This is used as the binding
interface on the references but the wrapper processing is failing
because the binding interface does not apparently specify any data
types.
I'm going to need a little help in tracking down which change has
caused the problem. So first things first does anyone have any
candidates off the top of their heads.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [2.x] Assembly otest regression
Posted by Simon Laws <si...@googlemail.com>.
Thanks Raymond, Looks good to me. I'm back to having all of the
Aseembly tests passing (well all but the base test case which we still
need to tun off somehow)
Simon
Re: [2.x] Assembly otest regression
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I can now run the ASM_4001 under Eclipse after the changes I made under [1].
Can you verify?
[1] http://svn.apache.org/viewvc?rev=881438&view=rev
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Tuesday, November 17, 2009 11:58 AM
To: <de...@tuscany.apache.org>
Subject: Re: [2.x] Assembly otest regression
> I think that sounds like a good proposal Raymond. I tried fixing the
> reference side but didn't meet immediate success because something
> else has gone wring somewhere.
>
> Originally when we instigated Endpoints the service they pointed to
> was the leaf most service in the promoted case. This was because the
> leaf most service is where messages must be delivered to ultimately.
> This was change though because doing this messes up the endpoints
> concept of its position in the model and it starts getting URIs wrong.
>
> A change was made in the wire creation code to take account of the
> fact that endpoints not pointed to the promoted service and not the
> leaf most service. I can't though find that code in the new scheme of
> things. I can't actually find it in the old scheme of things either
> but am still looking.
>
> The net result is that currently the reference is getting the wrong
> binding interface contraction in the local optimization case and hence
> the otest failures.
>
> Regards
>
> Simon
Re: [2.x] Assembly otest regression
Posted by Simon Laws <si...@googlemail.com>.
I think that sounds like a good proposal Raymond. I tried fixing the
reference side but didn't meet immediate success because something
else has gone wring somewhere.
Originally when we instigated Endpoints the service they pointed to
was the leaf most service in the promoted case. This was because the
leaf most service is where messages must be delivered to ultimately.
This was change though because doing this messes up the endpoints
concept of its position in the model and it starts getting URIs wrong.
A change was made in the wire creation code to take account of the
fact that endpoints not pointed to the promoted service and not the
leaf most service. I can't though find that code in the new scheme of
things. I can't actually find it in the old scheme of things either
but am still looking.
The net result is that currently the reference is getting the wrong
binding interface contraction in the local optimization case and hence
the otest failures.
Regards
Simon
Re: [2.x] Assembly otest regression
Posted by Raymond Feng <en...@gmail.com>.
Please read my note on the Interface contracts of
RuntimeEndpoint/RuntimeEndpointReference.
In this particular case, we optimize binding.sca by connecting the endpoint
reference invocation to the endpoint invocation chain. We choose to
transform the data within the endpoint reference invocation chain:
1) The source contract is the
sourceComponentType.reference.interfaceContract
2) We (should) set the bindingInterfaceContract for the endpoint reference
to be the targetComponentType.service.interfaceContract so that the data
will be transformed from databinding that the source component
implementation code uses to the one that target component implementation
code expects.
3) We (should) set the bindingInterfaceContract for the endpoint to be the
targetComponentType.service.interfaceContract so that no data transformation
is needed within the endpoint invocation chain.
If the target endpoint is remote, then it follows the regular split of
endpoint reference and endpoint. Each side would deal with the data
transformations between the binding layer and componentType requirements.
We could fix the RuntimeSCAReferenceBindingProvider and
RuntimeSCAServiceBindingProvider to set up the binding interface contract
according to proposal above.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Tuesday, November 17, 2009 6:57 AM
To: "tuscany-dev" <de...@tuscany.apache.org>
Subject: Re: [2.x] Assembly otest regression
> I note that RuntimeSCAReferenceBindingProvider method for retrieving
> the binding contract has changed from
>
> public InterfaceContract getBindingInterfaceContract() {
> if (isTargetRemote()) {
> return getDistributedProvider().getBindingInterfaceContract();
> } else {
> if (reference.getReference() != null) {
> return reference.getReference().getInterfaceContract();
> } else {
> return reference.getInterfaceContract();
> }
> }
> }
>
>
> to
>
> public InterfaceContract getBindingInterfaceContract() {
> if (isTargetRemote()) {
> return getDistributedProvider().getBindingInterfaceContract();
> } else {
> // Check if there is a target
> RuntimeEndpoint endpoint =
> (RuntimeEndpoint)endpointReference.getTargetEndpoint();
> if (endpoint != null) {
> // Use the target binding interface contract
> return endpoint.getBindingInterfaceContract();
> } else {
> return endpointReference.getReferenceInterfaceContract();
> }
> }
> }
>
> Which in the 4001 case returns the WSDL contract of the target
> service. So I imagine the resulting effect will be to try and convert
> the Jva types to WSDL types and then back again as messages pass end
> to end through the sca binding. Now this doesn't actually work for
> this test for some reason but I'd like to understand the intention.
>
> Simon
Re: [2.x] Assembly otest regression
Posted by Simon Laws <si...@googlemail.com>.
I note that RuntimeSCAReferenceBindingProvider method for retrieving
the binding contract has changed from
public InterfaceContract getBindingInterfaceContract() {
if (isTargetRemote()) {
return getDistributedProvider().getBindingInterfaceContract();
} else {
if (reference.getReference() != null) {
return reference.getReference().getInterfaceContract();
} else {
return reference.getInterfaceContract();
}
}
}
to
public InterfaceContract getBindingInterfaceContract() {
if (isTargetRemote()) {
return getDistributedProvider().getBindingInterfaceContract();
} else {
// Check if there is a target
RuntimeEndpoint endpoint =
(RuntimeEndpoint)endpointReference.getTargetEndpoint();
if (endpoint != null) {
// Use the target binding interface contract
return endpoint.getBindingInterfaceContract();
} else {
return endpointReference.getReferenceInterfaceContract();
}
}
}
Which in the 4001 case returns the WSDL contract of the target
service. So I imagine the resulting effect will be to try and convert
the Jva types to WSDL types and then back again as messages pass end
to end through the sca binding. Now this doesn't actually work for
this test for some reason but I'd like to understand the intention.
Simon