On Jan 4, 2013, at 6:28 AM, Peter Firmstone <[email protected]> wrote:
> Gregg Wonderly wrote: >> On Jan 3, 2013, at 6:58 AM, Peter Firmstone <[email protected]> wrote: >> >> >>> Gregg Wonderly wrote: >>> >>>> I too use static locator configuration because I am usually one of the >>>> administrators across a VPN connection, and my other users are remote >>>> users, not local to the multicast TTL. >>>> >>>> I wonder if we shouldn't think about a pluggable system something like >>>> URLStreamHandler. That is, an abstract class that has pluggable protocol >>>> handlers which could be added to the system via configuration, or >>>> programmatically via a security based authorization. Then, we can use >>>> LookupLocator, but just move to a multi-protocol lookup facility. >>>> >>> Currently we're restricted to jini://host:port URI syntax in LookupLocator, >>> although we have various options for discovery, these are goverened by >>> constraints, but then you have the problem of the client and server being >>> configured with different constraints and unicast discovery protocols. >>> >> >> I don't see such a restriction since there is a LookupLocator(String) >> constructor. That string can convey anything, and the history of "jini:" is >> just history, not a requirement. People using the other constructors get >> "jini:" behaviors. The getRegistrar(…) methods just need to use a pluggable >> protocol discovery/lookup function, and then return a ServiceRegistrar >> implementation. Whether or not that is a "remote" reference or a "proxy >> service" is a detail for the protocol provider. >> >> > > LookupLocatorDiscovery uses the host and port fields from LookupLocator, it > doesn't use getRegistrar(), although ConstrainableLookupLocator overrides > getRegistrar(), but it too uses the host and port fields from LookupLocator. > The host and port fields are parsed from a url string using URI during > construction. > > Any protocol other than jini:// throws a MalformedURLException. That is the current implementation. I am talking about what should be going on instead... >>> We already have a number of different discovery protocol options, it would >>> be nice if LookupLocator reflected this. >>> >> >> What are you imagining to be different? >> > Unicast Discovery Protocols: > Plain text discovery v1 & v2. > Kerberos > SSL > > For all these the URI scheme is still jini://host:port > > It's up to clients and servers to set constraints and these may not match. > There's also a migration issue for people with Discovery V1 deployments. > > The serialized form of LookupLocator, is simply: > > /** > * The name of the host at which to perform discovery. > * > * @serial > */ > private final String host; > /** > * The port number on the host at which to perform discovery. > * > * @serial > */ > private final int port; > > No invariant checks are performed during deserialization only during object > construction. > > Scheme, userInfo, path, query and fragment are missing. > > Although it could be argued that not all of these fields are important. > > Implications of additional fields: > > 1. Information is lost when deserialized in previous versions. LookupLocator is not something that should be "passed around". It is information that indicates a destination. The URL/URI form is all we should plan for, for the future. This means that all dynamically discovered ServiceRegistrar instances, should be identified as the URL string and then the appropriate protocol handler will be able to extract the information from the URL/URI to connect and provide lookup services. Gregg Wonderly
