Thanks for the tip on Reggie, good idea. I did think about deprecating LookupLocator, but Serialization and inheritance makes it impractical, the next best thing is change it to use Disco V2.
LookupLocator has a dual purpose, one an address to find a registrar and secondly to retrieve a registrar proxy using discovery V1, it's the second that's at issue, the first is basically just a uri starting with jini. The com.sun.jini.discovery.DiscoveryV1 and DiscoveryV2 classes contain the implementations. ----- Original message ----- > > ConstrainableLookupLocator is already a compatible replacement for > LookupLocator. Just mark LookupLocator as deprecated and don’t waste > any time on it. > > We might want to think about changing Reggie so it defaults to > DiscoveryV2. Right now v1 is the default. > > Greg Trasuk. > > On Jun 24, 2014, at 6:12 AM, Peter Firmstone <j...@zeus.net.au> wrote: > > > Presently, LookupLocator's method getRegistrar, discovers a lookup > > service, using Discovery V1 only. > > > > ConstrainableLookupLocator overrides the getRegistrar method and can > > perform Discovery V1 or V2. > > > > As a first step, in ensuring maximum compatibility, I'd like to > > propose changing LookupLocators implementation of getRegistrar to be > > identical to ConstrainableLookupLocator, but with > > InvocationConstraints.EMPTY, that is, without any constraints. > > > > Secondly, I'd like to propose that Discovery V2 is used by default, > > and Discovery V1 can only be used by setting a system property, for > > migration purposes only. > > > > Doing so will allow LookupLocator to function using either Discovery > > V1 or V2. > > > > This also reduces code duplication, presently there are two > > implementations of client side Discovery V1, this will reduce that to > > one implementation only. > > > > Regards, > > > > Peter. >
