Wow, I had not chased through all this code. I had assumed that
LookupLocatorDiscovery would use LookupLocator.getRegistrar() when in fact it
does not, and recreates all the processing itself and uses introspection to
reference the getRegistrarMethod for constraints, but otherwise does not call it.
Anyone from Sun have any comments on why getRegistrar() is not used by
LookupLocatorDiscovery?
Gregg Wonderly
Sim IJskes - QCG wrote:
Gregg Wonderly wrote:
Are there any other issues that we need to deal with in adding a new
constructor? I am wondering about "net.jini.discovery.timeout" as a
system property. Do we want to provide the ability to pass this into
the constructor too? I have cases where I want this to be short for
some locators and long for others, but have to go with the global
setting because of this implementation detail.
The LookupLocator is (in part) a value object. Its role, one of them, is
pointing to the place where we can find a Registry. I did a scan of the
sources, and i cannot find a place where another jini class actually
retrieves the registry from the LookupLocator.
So any implementation that retrieves the ServiceRegistrar can set the
individual timeout for the lookup with:
public ServiceRegistrar getRegistrar(int timeout)
I can foresee situations where this method isn't very helpfull to solve
the problem of per-locator timeouts.
Gr. Sim
