Agreed.
On Tue, Nov 13, 2012 at 6:57 PM, Gregg Wonderly <ge...@cox.net> 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 <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) > >>> > >>> > >>> > >>> > >>> > >> > > > >
