...snip > > The two sets of SPIs could co-exist for a while with BindingProviders > working with bindings and ServiceProviders (I just made up that name) with > service endpoints. > -- > Jean-Sebastien
At r656959 I've just enabled some changes to take a step toward using an Endpoint representation in the model as an alternative to using cloned bindings as the representation of valid reference targets. It's not replacing the cloned binding approach just yet, to avoid breaking anything, but is the first step on the road. This is what I have done. Made a new Endpoint model type Created a separate factory for it (separate as I though the model may need to be pluggable as some point) Created a new EndpointProvider type and associated factory. Created an Endpoint module to provide a provider implementation. Created an Endpoint wire to trap attempted calls over unresolved endpoints Separated off the Endpoint builder code into a new builder class. Same code but easier to identify. Added an endpoint collection to references Used the Endpoint in the wire builder in place of the old internal target structure. The logic is weaved in to the existing logic as follows. For references with no target, put the binding into reference binding as before Create an Endpoint for all explicit reference targets For resolved endpoints (Endpoints where the target is resolved) put the binding into reference bindings, i.e. the same as before For unresolved endpoints create an endpoint provider and a wire. We don't have unresolved targets in tuscany (except in the sca binding test) so should not happen. If you do put a target name in that can't be matched with a service you'll get a warning. If there is no Endpoint module on the classpath it will not create a provider or a wire hence disabling any Endpoint based processing. The Endpoint model will still be used though As part of this change I've updated the logic that looks for target names in binding uri. It's now applied to all binding types which I believe is what the spec says, There is though an issue here. I'll raise a separate thread. There are also a couple of thoughts I had. Can we make the CompositeBuilderImpl have just one constructor? Should builders be pluggable? I've used some of the CompoisteActivator functions in the EndpointWire that could do with moving into the activator interface. Simon
