|
From: Alon Bar-L. <alo...@gm...> - 2014-05-27 18:31:58
|
On Tue, May 27, 2014 at 8:43 PM, Neil A. Wilson <nei...@un...> wrote: > > On 05/18/2014 04:08 AM, Neil A. Wilson wrote: >> >> On 05/17/2014 06:44 AM, Alon Bar-Lev wrote: >>> >>> Hi, >>> >>> Have you reviewed this request? Adding Resolver interface class to >>> perform hostname->InetAddress resolution before calling the socket >>> factory is important to enable full control over the address selection >>> as required for most of the server sets. You have done this partially >>> at the SRVRecord implementation. >> >> >> This is something I am still considering for addition to the LDAP SDK at >> some point. > > > I have just committed a change that adds a new RoundRobinDNSServerSet class. This class provides support for a single hostname that resolves to multiple IP addresses. Because this scenario is typically referred to as a round-robin DNS configuration, I have named the server set that. However, note that the implementation does not strictly require the use of DNS (you can force its use by specifying a JNDI DNS provider URL, but you can also rely on the default name service mechanism which may look in other places like the /etc/hosts file or NIS). Also note that it does not require round-robin selection of addresses -- there are also options available to use a failover selection (in which it consistently uses addresses in the order retrieved from the server) or a randomized order. > > Thanks! These kind of changes are the exact ones that I was describe as may break my workaround :) Now we have public connect method that accepts InetAddress, in addition to host name, which is great. May I suggest that the following will return InetAddress instead of string? public String getConnectedIPAddress() Now the a common comment for both the srv record and the new dns srv record class, as I wrote previously... having a provider url is not enough, the dns provider is there to be able to customized. Please consider to add ability to accept Properties instead or in addition of URL. If the policy would not have been to have final classes, an inheritance should have been able to customize the properties before establish of context, but this is impossible in current restrictions. At least the following are important: com.example.jndi.dns.recursion com.example.jndi.dns.timeout.initial com.example.jndi.dns.timeout.retries Also which type of record to return is important, implementation should suppor AAAA and CNAME in addition to A. I would also suggest to create single jndi context for the entire processing of the class instead of one every lookup. Regards, Alon |
