[2.x] Accessing the reference binding information in a reference wired with @target attribute

[Luciano Resende <lu...@gmail.com>]

While bringing up the Implementation.widget, I have found the
following scenario : A component that has couple references wired via
@target attribute, and all the binding information is available in the
target service.
   ...
   <component name="Store">
        <tuscany:implementation.widget location="uiservices/store.html"/>
        <service name="Widget">
        	<tuscany:binding.http uri="/store"/>
        </service>
		<reference name="catalog" target="Catalog"/>
		 <reference name="shoppingCart" target="ShoppingCart/Cart"/>
		 <reference name="shoppingTotal" target="ShoppingCart/Total"/>
    </component>

	<component name="Catalog">
		<implementation.java class="services.FruitsCatalogImpl"/>
		<property name="currencyCode">USD</property>
		<service name="Catalog">
			<tuscany:binding.jsonrpc/>
   		</service>
		<reference name="currencyConverter" target="CurrencyConverter"/>	
	</component>
       ...

In the past, I could easily get access to the binding configuration
via the RuntimeComponent (e.g component.getReferences.getBinding()).
With the recent changes around EndPoint and EndPointReference, how am
I supposed to get access to these info during a invocation of my
extension ? I have tried couple variations without success (e.g
component.getEndpointReferences().get(0).getBinding() which always
return null, and
component.getEndpointReferences().get(0).getTargetEndpoint() which is
always unresolved)

Because I know there are several changes being done on this area at
the moment, I want to double check what should be the expected
behavior and the right approach to access the binding configuration
for the reference on the scenario above, before I start making any
changes on the in flux code.

-- 
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: [2.x] Accessing the reference binding information in a reference wired with @target attribute

[Luciano Resende <lu...@gmail.com>]

On Wed, Nov 18, 2009 at 6:56 AM, Simon Laws <si...@googlemail.com> wrote:
> Hi Luciano
>
> At what point were you calling
>
> component.getEndpointReferences().get(0).getTargetEndpoint() (which is
> always unresolved)
>
> Would be useful to see a toString() of the endpoint reference at that point.
>
> As a general rule the resolution of an EndpointReference happens in two stages.
>
> 1/ The builders create the endpoint reference and do as much work as
> they can given what information they have available. I.e. for a local
> reference in the same composite they set of the endpoint reference to
> point to a resolved endpoint (which get created before the endpoint
> references). Bindings won't be selected at this stage (although there
> as some cases where we could select the binding, see note * at the
> bottom)
>
> 2/ At run time, when the endpoint reference chain is created, an
> endoint has various levels of resolution applied to depending on what
> state it was left in by the builder, for example, a local reference
> just has its binding resolved while a reference across the domain will
> have both service and binding resolved)
>
> * I set the process up in these two stages to force us to think about
> situation, such as cross domain wiring, where a composite may be
> started before the services that it depends are are available. There
> is actually no particular functional justification why local
> references can't be fully resolved at build time. In fact it was set
> up to do that originally but the function was lost during one of the
> refactoring exercises.
>
> Regards
>
> Simon
>

I was able to get over this issue by explicitly calling
EndpointReference.getInvocationChains() if the targetEndpoint is
unresolved. This seems to properly resolve all the targetEndpoints and
then I could access the binding configuration to properly generate
Widget Client JS Proxy. I still think we might need to revisit this
and check if there is a bug that is causing the targetEndpoint to be
unresolved.

-- 
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: [2.x] Accessing the reference binding information in a reference wired with @target attribute

[Simon Laws <si...@googlemail.com>]

Hi Luciano

At what point were you calling

component.getEndpointReferences().get(0).getTargetEndpoint() (which is
always unresolved)

Would be useful to see a toString() of the endpoint reference at that point.

As a general rule the resolution of an EndpointReference happens in two stages.

1/ The builders create the endpoint reference and do as much work as
they can given what information they have available. I.e. for a local
reference in the same composite they set of the endpoint reference to
point to a resolved endpoint (which get created before the endpoint
references). Bindings won't be selected at this stage (although there
as some cases where we could select the binding, see note * at the
bottom)

2/ At run time, when the endpoint reference chain is created, an
endoint has various levels of resolution applied to depending on what
state it was left in by the builder, for example, a local reference
just has its binding resolved while a reference across the domain will
have both service and binding resolved)

* I set the process up in these two stages to force us to think about
situation, such as cross domain wiring, where a composite may be
started before the services that it depends are are available. There
is actually no particular functional justification why local
references can't be fully resolved at build time. In fact it was set
up to do that originally but the function was lost during one of the
refactoring exercises.

Regards

Simon