Indeed, I feel there's something slightly broken design-wise in adding a SocketFactory parameter to LookupLocator.
See the URL basically defines the kind of connectivity (consider http versus https) and thus the kind of socket used. It would be possible, for example, to pass a socket factory that produces sockets that aren't "compatible" with the URL type. The documentation would suggest there is only one type of URL acceptable: The syntax of the URL must be that of a *hierarchical* URI<http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html> with a *server-based naming authority*. Requirements for the components are as follows: - A *scheme* of "jini" must be present. - A *server-based naming authority* must be present; *user-info* must not be present. The *port*, if present, must be between 1 and 65535 (both included). If no port is specified, a default value of 4160 is used. - A *path* if present, must be "/"; *path segment*s must not be present. - There must not be any other components present. Which implies a socket factory isn't required because there's only one way to "do" unicast and it's all taken care of under the covers. Thus adding a socket factory implies a change to the mechanism for discovery and support for different kinds of URLs etc. So, when we added a socket factory, what were we trying to do? That might then tell us a bit more about the vector of solutions we're looking at. On 14 November 2012 02:57, Gregg Wonderly <[email protected]> wrote: > Of course, the practical matter, is that in this day and age, server port > numbers indicate specific types of services for the things in > /etc/services. But, really, we should move the whole discovery business > away from "socket creation parameters" and into a "mechanism" using an > interface or abstract class so that through Configuration, it would be > pluggable at deployment. > > Gregg > > On Nov 13, 2012, at 6:05 PM, Peter <[email protected]> wrote: > > > Hi Greg, > > > > LookupLocatorDiscovery uses LookupLocator to find a Registrar, however > it only uses the host name and port, it doesn't use LookupLocator to > perform discovery. > > > > LookupLocator requires a defined static port, otherwise 4160 is used if > no port is defined. > > > > Recently a SocketFactory was added to LookupLocator, however this is > only used by the obsolete version 1 discovery in LookupLocator and not by > LookupLocatorDiscovery. > > > > LookupLocator is also Serializable, but it's constructed with multicast > discovery where the SocketFactory cannot be transferred. > > > > It seems we'd be better off using URI, in fact when LookupLocator is > constructed, it uses URI to assist parsing the host name and port. > > > > Instead of mandating Socket we could consider using a jeri Endpoint. > > > > A URI scheme provider could be used for plugging in different schemes to > obtain the Endpoint. > > > > This might allow the use of maven provisioning or similar to obtain an > unknown scheme or Endpoint. > > > > This would allow plugging in dns-srv URI's and other unknown future > protocols for obtaining a registrar proxy. > > > > A default jini://host:port provider can be supplied for backward > compatibility. > > > > Thoughts? > > > > Peter. > > > > > > ----- Original message ----- > >> > >> On Tue, 2012-11-13 at 08:31, Peter Firmstone wrote: > >>> Presently LookupLocator is practically a URI of the form > >>> "jini://hostname:port" > >>> > >>> LookupLocator is constructed during multicast discovery at the client. > >>> > >>> ConstrainableLookupLocator is a subclass that implements constraints. > >>> > >>> LookupLocatorDiscovery also accepts LookupLocator to perform unicast > >>> discovery using constraints. > >>> > >>> We modified LookupLocator to accept a SocketFactory via a constructor > >>> (approx 2 years ago). > >>> > >>> LookupLocator is built around tcp, but there are obviously many > protocols. > >>> > >>> Any ideas? > >> > >> I'm not sure I understand the question. Is there a problem with > >> LookupLocator? > >> > >> Cheers, > >> > >> Greg. > >> > >>> > >>> Oh I found a bug in LookupLocator on ARM btw: > >>> > >>> Seems to be something wrong with the parser, dropping the port number, > >>> getting closer to fixing it at least now I know why port 4160 is always > >>> in use ;). > >>> > >>> BaseQATest.startInitLookups FINE: initial lookups started != initial > lookups > >>> wanted BaseQATest.startInitLookups FINE: initial lookups started -- > >>> BaseQATest.displayLookupStartInfo FINE: # of lookups = 3 > >>> BaseQATest.displayLookupStartInfo FINE: locator lookup[0] = > >>> ConstrainableLookupLocator[[jini://je-cal-12.apache.org:37955/], > [null]] > >>> GroupsUtil.displayGroupSet FINE: group[0] = > >>> LLDGroup0_A_je-cal-12_1352811309324 GroupsUtil.displayGroupSet FINE: > >>> group[1] = LLDGroup0_B_je-cal-12_1352811309324 > GroupsUtil.displayGroupSet > >>> FINE: group[2] = LLDGroup0_C_je-cal-12_1352811309324 > >>> BaseQATest.displayLookupStartInfo FINE: locator lookup[1] = > >>> ConstrainableLookupLocator[[jini://je-cal-12.apache.org:49744/], > [null]] > >>> GroupsUtil.displayGroupSet FINE: group[0] = > >>> LLDGroup1_A_je-cal-12_1352811309324 GroupsUtil.displayGroupSet FINE: > >>> group[1] = LLDGroup1_B_je-cal-12_1352811309324 > GroupsUtil.displayGroupSet > >>> FINE: group[2] = LLDGroup1_C_je-cal-12_1352811309324 > >>> GroupsUtil.displayGroupSet FINE: group[3] = > >>> LLDGroup1_D_je-cal-12_1352811309324 BaseQATest.displayLookupStartInfo > FINE: > >>> locator lookup[2] = > >>> ConstrainableLookupLocator[[jini://je-cal-12.apache.org:57373/], > [null]] > >>> GroupsUtil.displayGroupSet FINE: group[0] = > >>> LLDGroup2_A_je-cal-12_1352811309324 GroupsUtil.displayGroupSet FINE: > >>> group[1] = LLDGroup2_B_je-cal-12_1352811309324 > GroupsUtil.displayGroupSet > >>> FINE: group[2] = LLDGroup2_C_je-cal-12_1352811309324 > >>> BaseQATest.startInitLookups FINE: initial lookups wanted -- > >>> BaseQATest.displayLookupStartInfo FINE: # of lookups = 3 > >>> BaseQATest.displayLookupStartInfo FINE: locator lookup[0] = > >>> ConstrainableLookupLocator[[jini://je-cal-12.apache.org:4160/], > [null]] > >>> GroupsUtil.displayGroupSet FINE: group[0] = > >>> LLDGroup0_A_je-cal-12_1352811309324 GroupsUtil.displayGroupSet FINE: > >>> group[1] = LLDGroup0_B_je-cal-12_1352811309324 > GroupsUtil.displayGroupSet > >>> FINE: group[2] = LLDGroup0_C_je-cal-12_1352811309324 > >>> BaseQATest.displayLookupStartInfo FINE: locator lookup[1] = > >>> ConstrainableLookupLocator[[jini://je-cal-12.apache.org:4160/], > [null]] > >>> GroupsUtil.displayGroupSet FINE: group[0] = > >>> LLDGroup1_A_je-cal-12_1352811309324 GroupsUtil.displayGroupSet FINE: > >>> group[1] = LLDGroup1_B_je-cal-12_1352811309324 > GroupsUtil.displayGroupSet > >>> FINE: group[2] = LLDGroup1_C_je-cal-12_1352811309324 > >>> GroupsUtil.displayGroupSet FINE: group[3] = > >>> LLDGroup1_D_je-cal-12_1352811309324 BaseQATest.displayLookupStartInfo > FINE: > >>> locator lookup[2] = > >>> ConstrainableLookupLocator[[jini://je-cal-12.apache.org:4160/], > [null]] > >>> GroupsUtil.displayGroupSet FINE: group[0] = > >>> LLDGroup2_A_je-cal-12_1352811309324 GroupsUtil.displayGroupSet FINE: > >>> group[1] = LLDGroup2_B_je-cal-12_1352811309324 > GroupsUtil.displayGroupSet > >>> FINE: group[2] = LLDGroup2_C_je-cal-12_1352811309324 > >>> BaseQATest.tearDown FINE: tearDown - terminating lookup service(s) > >>> > >>> > >>> > >>> > >>> > >> > > > >
