Simon Laws wrote:
Hi
There is now a test in the binding name creation code that checks that two
service bing types are the same before testing for duplicate names. I don't
think the binding type is relevant here. We should actually be testing that
the scheme that the bindings intend to use are the same but that information
is not easily available. With the current change we can say
<binding.ws name="fred"/>
<binding.jsonrpc name="fred"/>
and I don't believe the code will complain.
and that's OK I think :) as binding.ws and binding.jsonrpc could end up
on different port numbers for example (depending on their node
configuration).
Actually, I was struggling to understand why we needed this test for
duplicate names at all.
Does the spec forbids two bindings with the same name?
By trying hard to detect duplicate names early on (without having all
the info about what the binding URIs will end up to be), won't we raise
errors even for cases that should work?
One example of the issues I was running into:
<service...>
<binding.jsonrpc/>
<binding.ws uri="/whatever">
</service>
throwing a duplicate name exception as the two bindings had the same name.
On a fun note, I think that:
<service name="aservice">
<binding.jsonrpc name="whatever"/>
<binding.ws uri="/whatever">
</service>
would probably not have thrown an exception, but should have :)
So my recommendation would be to not try too hard to detect these
duplicates early on based on binding names (as the detection algorithm
is too fragile at that point), instead detect duplicates at the very end
when we see that we end up with duplicate URIs.
Also can you give a quick example the problems you found relating to "avoid
adding binding name to itself, and consider binding URI when specified in
the composite in the single service case too" so I can understand the other
code changes.
One issue was that the code was not considering the binding URI when
there was only one service on a component, for example IIRC:
<component name="Store">
<service name="Widget">
<binding.http uri="/ui"/>
</service>
</component>
was bound to /Store (the component URI) instead of /ui.
I understand that the binding name should be omitted from the computed
URI in the single service case, but the binding URI should be considered
if specified, leading to the requirement to distinguish between binding
name (always know, not always considered) and binding URI (not always
specified, always considered when specified).
About the "adding the binding name to itself" part, this is a little
complicated. IIRC the issue was that CompositeConfigurationBuilder would
first convert:
<component name="Foo">
<service...>
<binding.sca/>
</service>
</component>
into:
<component name="Foo">
<service...>
<binding.sca uri="Foo"/>
</service>
</component>
Then when an SCANode would consume that, CompositeBuilder.build would
turn it into:
<component name="Foo">
<service...>
<binding.sca uri="Foo/Foo"/>
</service>
</component>
as I think the old CompositeConfigurationBuilder code used in that case
used to concatenate the component URI and the binding URI.
Thanks
Simon
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
