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
On 13-11-12 14:31, Peter Firmstone wrote:
Oh I found a bug in LookupLocator on ARM btw:
Ok, we should leave the ARM port for the next release then.
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
One possibility may be to consider makeing LookupLocator an interface
given that there are only two methods that really matter.
Implementations could support a socket based protocol like it is now
and other protocols in the future. I know that this would affects
current deployments; but it gives
See https://builds.apache.org/job/River-QA-ubuntu-jdk7/60/changes
Changes:
[peter_firmstone] Debugging tests on arm platform to gather more information.
[peter_firmstone] Debugging tests on arm platform to gather more information.
[peter_firmstone] Debugging tests on arm platform to gather
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
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
