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 <j...@zeus.net.au> 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) >>> >>> >>> >>> >>> >> >
