Hi guys,
for the ease of use I stumbled upon a few things that would make my life easier:

• Make BaseResolverConfigProvider public

I need to verify it there are no unintended side effects on certain methods, but yes, should be doable.

• Provide me with a way to read the existing ResolverConfig.configProviders (so that I can "add" one without needing to copy paste all of them)

For consistency sake of matching get/set, yes. But would you mind to explain your use case? If you want to add a config provider don't you know which one you want to use and explicitly avoid probing the built-ins?

• Can you make ExtendedResolver.DEFAULT_TIMEOUT public? It's immutable anyway

Yes.

• Can you provide ExtendedResolver with getters for the fields "loadBalance" and "retries"?

Yes.

Getters for the SimpleResolver field may not be bad either.

Not sure I don't understand this one, do you mean getters on the SimpleResolver class?

• Can you provide SimpleResolver with equals/hashCode so that it can be easily used in a Set?

I'm very hesitant about this as it would require making SimpleResolver immutable. Assuming you'd base equals on the used DNS server+port, isn't that something you could easily handle with a Map?

Thanks.

@ibauersachs thanks for the swift response.

For consistency sake of matching get/set, yes. But would you mind to explain your use case? If you want to add a config provider don't you know which one you want to use and explicitly avoid probing the built-ins?

I basically want to add another resolver that takes custom DNS servers (Google DNS and Cloudflare in my scenario) that should act as the last ressort for out beloved Windows users without JNA. So I basically want add one more ResolverConfigProvider instance to the default resolver config

Not sure I don't understand this one, do you mean getters on the SimpleResolver class?

Yes for the basic stuff.

I'm very hesitant about this as it would require making SimpleResolver immutable. Assuming you'd base equals on the used DNS server+port, isn't that something you could easily handle with a Map?

I guess so - I was not sure myself if this is reasonable or not. But since InetSocketAddress has equals/hashCode I guess I'd be fine with the Map approach

Another possible extension would be to use SPI (https://docs.oracle.com/javase/tutorial/ext/basics/spi.html in case you don't know it) to allow for initial "one time startup configuration" where I could add my own "ResolverConfigProvider"?

Small P.S.:

• Make BaseResolverConfigProvider public

As ResolverConfigProvider is implemented pretty easily, it might not be necessary if this creates too much headaches....

@ibauersachs thanks for the swift response.

For consistency sake of matching get/set, yes. But would you mind to explain your use case? If you want to add a config provider don't you know which one you want to use and explicitly avoid probing the built-ins?

I basically want to add another resolver that takes custom DNS servers (Google DNS and Cloudflare in my scenario) that should act as the last ressort for out beloved Windows users without JNA. So I basically want add one more ResolverConfigProvider instance to the default resolver config

When is that the case? dnsjava isn't an application, so if you (as a developer) use dnsjava, you can include JNA as a non-optional dependency.

However, I like the idea of having the fallback resolver configurable instead of statically using localhost. So how about an included FallbackConfigProvider that takes the same format as PropertyResolverConfigProvider but with different property names, e.g. dns.fallback.XYZ?

Another possible extension would be to use SPI (https://docs.oracle.com/javase/tutorial/ext/basics/spi.html in case you don't know it) to allow for initial "one time startup configuration" where I could add my own "ResolverConfigProvider"?

I considered using the SPI for the built-in providers, but it's not possible to get a (custom) sorted list from ServiceLoader. While it would be possible to just make custom SPIs first or last (in any order), I don't think this would be desirable.

Basically I need a cross-plattform DNS client that speaks NAPTR so I don't have too many choices :-)
I don't include JNA, bause the operating system specific Maven profiles can become tedious when runnning with multiple Java versions in multiple environments. If you than also create Docker images it gets additionally messy. Therefore a customizable fallback with 0..n servers seems to be a good idea, as long as the underlying properties file is resolved from the classpath.
I would keep localhost as the last ressort if even that one is not present.

Concerning the SPI suggestion, I see 2 reasonable solutions:

1. Create an SPI interface that supports "addPrimary" and "addLast" (or 2 SPIs)
2. Add priorities to the ResolverConfigs, give the existing ones predefined priorities (the higher the more important) and sort after resolving the SPI implementations...

v3.2.0 is released

Cool thanks - very helpful :) Keep up the good work