On Thu, Jan 21, 2010 at 4:44 PM, Raymond Feng <[email protected]> wrote: > There are two use cases that led the current scheme-based delegation: >
Heh, isn't it just because I started using using the scheme based approach in various places as an easy way to get the tribes registry configured? > There are a few tweaks we can do to make the current code more flexible > though: > > a) Add an extension point named DomainRegistryProviderExtensionPoint > > b) Rename DomainRegistryFactory to be DomainRegistryProvider. The providers > will be registered to the DomainRegistryProviderExtensionPoint. Each > provider can support one or more URI schemes. The > DomainRegistryProviderExtensionPoint can either lookup the > DomainRegistryProvider by scheme, or simply loop through the > DomainRegistryProvider instances to find the provider that can handle the > registry URI. > > c) DomainRegistryProvider will have a method getDomainRegistry(domainURI) > to return an EndpointRegistry (should be renamed to DomainRegistry) instance > for the given SCA domain. > We can add another extension point, and thats what I was about to do but it seems unnecessary so I thought i first try posting about cleaning this up and simplifying things. There is a lot of old code around this that we really should clean up, left from the various attempts to get pieces of the distributed domain working and most of it has no tests or doc or use cases or ML discussion. We don't have support for running multiple impls concurrently of anything else - host-jetty/tomcat or any other extension - is this registry case really so different? ...ant
