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
|