On Nov 23, 2007 11:27 PM, Simon Nash <[EMAIL PROTECTED]> wrote: > > Simon Laws wrote: > > > On Nov 20, 2007 6:47 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> > > wrote: > > > > > >>Simon Laws wrote: > >> > >>>On Nov 20, 2007 3:59 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> > >>>wrote: > >>> > >>> > >>>>Are you sure that this is the right semantics? Can you help me > >>>>understand why we need to change the naming of the service if there's > a > >>>>a callback? > >>>> > >>>>Thanks. > >>>> > >>>> > >>>>[EMAIL PROTECTED] wrote: > >>>> > >>>>>Author: slaws > >>>>>Date: Tue Nov 20 06:35:45 2007 > >>>>>New Revision: 596692 > >>>>> > >>>>>URL: http://svn.apache.org/viewvc?rev=596692&view=rev > >>>>>Log: > >>>>>TUSCANY-1914 > >>>>>Construct URLs as ComponentName/ServiceName if callbacks have been > >> > >>added > >> > >>>>causing the number of services to be greater than 1 > >>>> > >>>>>Modified: > >>>>> > >>>> > > >>incubator/tuscany/java/sca/modules/assembly/src/main/java/org/apache/tuscany/sca/assembly/builder/impl/CompositeConfigurationBuilderImpl.java > >> > >>>>>Modified: > >>>> > > >>incubator/tuscany/java/sca/modules/assembly/src/main/java/org/apache/tuscany/sca/assembly/builder/impl/CompositeConfigurationBuilderImpl.java > >> > >>>>>URL: > >>>> > >> > http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/assembly/src/main/java/org/apache/tuscany/sca/assembly/builder/impl/CompositeConfigurationBuilderImpl.java?rev=596692&r1=596691&r2=596692&view=diff > >> > > >>============================================================================== > >> > >>>>>--- > >>>> > > >>incubator/tuscany/java/sca/modules/assembly/src/main/java/org/apache/tuscany/sca/assembly/builder/impl/CompositeConfigurationBuilderImpl.java > >> > >>>>(original) > >>>> > >>>>>+++ > >>>> > > >>incubator/tuscany/java/sca/modules/assembly/src/main/java/org/apache/tuscany/sca/assembly/builder/impl/CompositeConfigurationBuilderImpl.java > >> > >>>>Tue Nov 20 06:35:45 2007 > >>>> > >>>>>@@ -280,7 +280,8 @@ > >>>>> > >>>>> String bindingURI; > >>>>> if (binding.getURI() == null) { > >>>>>- if (componentServices.size() > 1) { > >>>>>+ //if (componentServices.size() > 1) { > >>>>>+ if (component.getServices().size() > 1) { > >>>>> // Binding URI defaults to component URI > >> > >>/ > >> > >>>>binding name > >>>> > >>>>> bindingURI = String.valueOf( > >> > >>binding.getName > >> > >>>>()); > >>>> > >>>>> bindingURI = URI.create(component.getURI > >> > >>() > >> > >>>>+ '/').resolve(bindingURI).toString(); > >>>> > >>>>> > >>>>>--------------------------------------------------------------------- > >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>>> > >>>> > >>>>-- > >>>>Jean-Sebastien > >>>> > >>>>--------------------------------------------------------------------- > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>>Maybe I'm getting the wrong end of the stick here. > >>> > >>>When a callback is encountered on a component reference a new callback > >>>service is now created to represent the endpoint of the callback > >>>[createCallbackService(Component, ComponentReference) in the > >>>CompositeConfigurationBuilder]. > >>> > >>>I believe the intention is to treat these new services in the same way > >> > >>as > >> > >>>any other service that the component may be providing. > >> > >>There's a difference, they cannot be wired to using <reference > >>target="...">. > >> > They can't be wired, but they can be looked up using createSelfReference() > and getService(). This is necessary to allow them to be passed as > service references on the setCallback() API. > > For wiring, createSelfReference(), and getService(), it is always > possible to identify services by the fully qualified component/service > name. In addition, if there is only one service on the component > (counting both regular explicit services and implicit services for > callbacks), it should be possible to specify the component name > alone as a shorthand. > > So far so good. Now we get to the trickier case of how URIs are > constructed for these services. For regular explicit services, the > approach in the spec is inconsistent with how this works for wiring > etc. as described above. The difference is that you either get a > fully qualified component/service name or you get a shorthand > component name only. > > The either/or/only part of the last sentence has very undesirable > consequences in the following scenario: > 1. A component has a single service A exposed via the shorthand URI. > 2. Other bindings or non-SCA clients refer to it using the shorthand URI. > 3. Another service B is added to the component. Now both A and B > are exposed via fully qualified URIs. > 4. Everyone who was referring to A by the shorthand URI is now broken. > > It's just as bad in the reverse scenario: > 1. A component has a two services A and B exposed via fully qualified > URIs. > 2. Other bindings or non-SCA clients refer to A using a fully qualified > URI. > 3. Service B is removed from the component. Now A is only exposed via > a shorthand URI. > 4. Everyone who was referring to A by the fully qualified URI is now > broken. > > The problem can be solved by always exposing services by the fully > qualified > URI. In the case where there's a single service on a component, it would > be possible to also provide an "unsafe" alias shorthand URI that cannot be > relied on for forward compatibility, but I can't see that it's worth > adding > this complexity for so little benefit. > > I have raised a spec issue for this. > > Simon > > >>I think it would be worth checking the intention with the spec group. > >> > >>Perhaps we should also check that the spec's intention is to continue to > >>have this one service vs multiple services distinction. I can't seem to > >>find it now on the mailing lists but I think I remember a discussion > >>around that and people suggesting to remove that distinction. > >> > >>-- > >>Jean-Sebastien > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >>Yes - I remember that too. I'll raise a question with Mike Edwards or > > > > someone on the spec group and see if we can get some resolution to this. > > Resolving the second question makes the first a moot point. > > > > Regards > > > > Simon > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Thanks for doing that Simon, I just saw the issue you raised on the OASIS list.
I also don't see any real advantage to be had by specifying the unsafe shorthands to identify component services. Simon
