|
From: Alon Bar-L. <alo...@gm...> - 2014-05-18 11:52:23
|
On Sun, May 18, 2014 at 12:08 PM, Neil A. Wilson
<nei...@un...> 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.
>
> However, since this can be implemented using public interfaces that the LDAP
> SDK already provides exactly for this kind of purpose, and because you
> indicated you had already created your own implementation that does this, I
> consider it to be a pretty low priority item compared with a vast amount of
> other work that I have to do.
>
Thank you for considering.
However, I must state again that there is no actual "public
interfaces" that already provides for this functionality. The
SocketFactory interface that is used supports already resolved
addresses, this conflicts with the requirement of having custom
resolver.
My solution is implementation specific to the behaviour of the ldap
sdk at this point in time, which may be broken any time without notice
and without any modification within the public interfaces, as it
relays on the subset use of SocketFactory by the ldap sdk.
Regards,
Alon
>>
>> It would be great to be able to control the dns lookup via all
>> available options[1], this suggest not only accepting the URL, but be
>> able to leverage all options, or use other than JNDI resolver
>> implementation.
>>
>> In order to temporary workaround this I created my own SocketFactory
>> that assumes that implementation always passes host name and never
>> address. However, this assumption is not valid within the generic
>> context.
>>
>> I suggest a simple interface similar to:
>>
>> interface Resolver {
>> InetAddress resolve(String host)
>> throws UnknownHostException;
>>
>> List<String> resolveSRVRecord(String service, String protocol, String
>> name)
>> throws UnknownHostException;
>> }
>>
>> Regards,
>> Alon Bar-Lev.
>>
>> [1] docs.oracle.com/javase/7/docs/technotes/guides/jndi/jndi-dns.html
>>
>> On Sun, May 11, 2014 at 9:22 AM, Alon Bar-Lev <alo...@gm...>
>> wrote:
>>>
>>> On Sat, May 10, 2014 at 2:40 AM, Alon Bar-Lev <alo...@gm...>
>>> wrote:
>>>>
>>>> On Sat, May 10, 2014 at 12:30 AM, Alon Bar-Lev <alo...@gm...>
>>>> wrote:
>>>>>
>>>>> On Sat, May 10, 2014 at 12:23 AM, Neil A. Wilson
>>>>> <nei...@un...> wrote:
>>>>>>
>>>>>> On 05/09/2014 03:30 PM, Alon Bar-Lev wrote:
>>>>>>>
>>>>>>>
>>>>>>> First feature request... ServerSet that uses DNS JNDI, to bypass java
>>>>>>> name cache and allow random selection of address if multiple exists.
>>>>>>> Similar to SRVRecord.
>>>>>>
>>>>>>
>>>>>>
>>>>>> This is something I will look into. However, ServerSet is an
>>>>>> @Extensible
>>>>>> API and this definitely falls into the purview of code that you can
>>>>>> write
>>>>>> for yourself and include in your own application. It would be
>>>>>> completely
>>>>>> possible for you to implement without altering any code within the
>>>>>> LDAP SDK
>>>>>> itself.
>>>>>
>>>>>
>>>>> I know, however, I do think it is missing common usable bit per what
>>>>> you distribute, per your suggestion to avoid maintaining own code.
>>>>
>>>>
>>>> BTW: It may be wise to add resolver entity to all classes that resolve
>>>> host name. This way there will be no need to re-write/modify all the
>>>> nice SeverSet implementations.
>>>>
>>>> For example the RoundRobin, FailoverServerSet, FastestConnectServerSet
>>>> can all benefit from be able to resolve host into multiple addresses
>>>> and work with dynamic dns updates such as load balancer if we detach
>>>> the name resolution from java.
>>>>
>>>> For now I will probably reimplement that, I would have sent a patch,
>>>> but...
>>>>
>>>
>>> For now I created my own SocketFactory that perform the resolve, as
>>> within code the implementation always creates a socket by name.
>>>
>>> However, as the interface accepts SocketFactory in future the
>>> implementation can call the factory with InetAddress instead of name
>>> and without proper name, and break custom resolver.
>>>
>>> The only solution I see without applying restriction on the
>>> SocketFactory is to add Resolver interface for all classes to use,
>>> calling SocketFactory always with InetAddress.
>>>
>>> This has some implication on the migration socket factory this
>>> interface does expect host name, but I guess it will be able to work
>>> with ip as well.
>>>
>>> Regards,
>>> Alon
>>
>>
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.
>> Get unparalleled scalability from the best Selenium testing platform
>> available
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> ldap-sdk-discuss mailing list
>> lda...@li...
>> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>
|
