Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds ResolverConfigTest #51

Merged
merged 6 commits into from Jun 4, 2019
Merged

Conversation

@kingle
Copy link
Collaborator

@kingle kingle commented Jun 2, 2019

  • Adding some tests to help with upcoming refactoring of ResolverConfig to allow SPI and also to sanity check the move of the properties files still works when testing on Windows.
  • Changed many findX methods in ResolverConfig to return boolean on success/failure to aid in testing
  • Minor change to add a package-private fromConstantString method to set origin, also to aid in testing
  • Moved non-java related resources to appropriate src/main/resources and src/test/resources
  • Removed spi-up-to-java8 profile -- unneeded now in the master branch
if (OS.contains("95") ||
OS.contains("98") ||
OS.contains("ME"))
if (Stream.of("95", "98", "ME").anyMatch(OS::contains))
Copy link
Collaborator Author

@kingle kingle Jun 2, 2019

Do we still want to support these ancient Windows versions?

Copy link
Member

@ibauersachs ibauersachs Jun 2, 2019

No

@@ -4,4 +4,5 @@
.idea/
*.iml
target/
.DS_Store
Copy link
Member

@ibauersachs ibauersachs Jun 2, 2019

This piece of b*s* still exists?

Copy link
Collaborator Author

@kingle kingle Jun 2, 2019

yep, still exists even on macOS Mojave

public class ResolverConfig {

static final String DNS_SERVER_PROP = "dns.server";
Copy link
Member

@ibauersachs ibauersachs Jun 2, 2019

I'd probably make these public to allow users to reference the properties via this constant. And please drop the indent for now.

Copy link
Collaborator Author

@kingle kingle Jun 4, 2019

Made public, dropped indent (when is the mass test formatting happening?)

Copy link
Member

@ibauersachs ibauersachs Jun 4, 2019

Not sure yet, if no pull requests are open. And only on test sources anyway. I haven't decided to apply it on the main sources yet since they're not so messy.

find95();
else
findNT();
findWin();
Copy link
Member

@ibauersachs ibauersachs Jun 2, 2019

Are you still working on a more SPI like interface, e.g. using ServiceLoader?

Copy link
Collaborator Author

@kingle kingle Jun 2, 2019

Yes

try {
Process p;
p = Runtime.getRuntime().exec("ipconfig /all");
findWin(p.getInputStream());
found = findWin(p.getInputStream());
Copy link
Member

@ibauersachs ibauersachs Jun 2, 2019

Is netsh int ipv4 show dnsservers or netsh int ipv6 show dnsservers also locale-dependent? I don't have a non-english Windows at hand right now. Otherwise we could switch to it (netsh should be available on Win 7+, and I don't care about MS unsupported Windows versions).

Copy link
Collaborator Author

@kingle kingle Jun 2, 2019

netsh is still locale-dependent (on my Windows 10 with Spanish set):

C:\...>netsh int ipv4 show dnsservers
Configuración para la interfaz "Ethernet"
    Servidores DNS configurados a través de DHCP:  192.168.1.1
    Registrar con el sufijo:           Solo el principal
...

That said, it's probably a better source to parse since it eliminates most of the noise

Copy link
Member

@ibauersachs ibauersachs Jun 3, 2019

It lacks the search domains though, not sure atm. if there's another netsh call for those.

Copy link
Collaborator Author

@kingle kingle Jun 3, 2019

I still think we should consider the registry option. What's wrong with looking at:
regedit /e TEMPFILE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters"
and parse those?

Copy link
Member

@ibauersachs ibauersachs Jun 3, 2019

You'll get nameservers of NICs with a disconnected link. Example: laptop with a wired and WiFi NIC. WiFi is connected at home to your router and the DHCP server assigns an IP and DNS addresses. Later you go to work, connect via cable (e.g. docking station), WiFi is disconnected. Your regedit call (and what Java does internally with probing the registry and calling Windows 95 (!) networking APIs) will get the inaccessible nameservers of your home WiFi.
Or the other way around (office nameservers still on the wired NIC, now only a WiFi connection). Querying the registry for this info is just completely wrong. See also JDK-7006496.

What I'd be fine with though is adding an optional (i.e. scope=provided) dependency to JNA, probing at runtime if it's available and then doing proper calls to Iphlpapi. But that API isn't easy.

Copy link
Collaborator Author

@kingle kingle Jun 3, 2019

name servers sure, but what about search suffixes? Regardless of whether you disconnect and reconnect at different places, do the DNS Search Suffixes change?

Copy link
Member

@ibauersachs ibauersachs Jun 3, 2019

Yes, they do change, at least their priority. At work I have ds.example.com, at home my cable router hands out home. Fritz Boxes (popular routers/modems in Europe and especially Germany) assign fritz.box.

Copy link
Collaborator Author

@kingle kingle Jun 3, 2019

Interesting. Can we table this for a different PR/issue? How we go about adding new functionality to better handle Windows resolution specifically could go on for awhile and we probably should discuss it in a separate issue. I definitely don't want to tackle native code additions here.

Copy link
Member

@ibauersachs ibauersachs Jun 3, 2019

Sure, this was just about the question if netsh is also locale dependent. It is, so, bummer.

Copy link
Collaborator Author

@kingle kingle Jun 3, 2019

Logged issue #55 to track the work to call Iphlpapi

String[] dnsSearch = { "dnsjava.org", "example.com",
"dnsjava.org" };
Name[] searchPath = Arrays.stream(dnsSearch)
.map(s -> Name.fromConstantString(s, Name.root))
Copy link
Member

@ibauersachs ibauersachs Jun 2, 2019

If this call is the only reason you added Name.fromConstantString(String, Name), why don't you simply put the trailing dot for the root to the string array?

Copy link
Collaborator Author

@kingle kingle Jun 2, 2019

Future tests may look at the inputs from other sources for search path (ipconfig output), and those sources usually don't have the trailing dot. We could adjust the inputs, but I feel conflicted relying on massaging test resources to have trailing dots. That being said, it's your call. I can go either way.

Copy link
Member

@ibauersachs ibauersachs Jun 3, 2019

The overload is anyway not necessary, this is equivalent: Name[] searchPath = Arrays.stream(dnsSearch).map(s -> Name.fromConstantString(s + "."))

Copy link
Collaborator Author

@kingle kingle Jun 4, 2019

Updated and reverted the Name addition

}

@Test
@EnabledOnOs({OS.LINUX, OS.MAC, OS.AIX, OS.SOLARIS})
Copy link
Member

@ibauersachs ibauersachs Jun 2, 2019

Or @DisabledOnOs({OS.WINDOWS})? I doubt any test run will ever be executed on Android - if it's detected at all.

Copy link
Collaborator Author

@kingle kingle Jun 2, 2019

Agreed. Changed in latest

findUnix() {
findResolvConf("/etc/resolv.conf");
return findResolvConf("/etc/resolv.conf");
Copy link
Member

@ibauersachs ibauersachs Jun 2, 2019

Can we pass an InputStream to findResolvConf (and wrap the Files.newInputStream(Paths.get("...")) into an auto-close try)?

Copy link
Collaborator Author

@kingle kingle Jun 2, 2019

Yes! Done in latest commit.

@Test
void resolvConfLoaded() throws URISyntaxException {
assertTrue(ResolverConfig.getCurrentConfig()
.findResolvConf(Paths.get(getClass()
Copy link
Member

@ibauersachs ibauersachs Jun 2, 2019

ResolverConfigTest.class.getResourceAsStream("/...")

@@ -194,24 +194,6 @@
</dependencies>

<profiles>
<profile>
Copy link
Member

@ibauersachs ibauersachs Jun 2, 2019

The service descriptor still needs to be excluded from the JAR on Java 9+. But it can probably be moved to the no-spi-on-java9 profile with an exclusion instead of an inclusion if you move it (correctly so, I missed that).

Copy link
Collaborator Author

@kingle kingle Jun 2, 2019

Good call. Excluded in that profile.

String[] dnsSearch = { "dnsjava.org", "example.com",
"dnsjava.org" };
Name[] searchPath = Arrays.stream(dnsSearch)
.map(s -> Name.fromConstantString(s, Name.root))
Copy link
Member

@ibauersachs ibauersachs Jun 3, 2019

The overload is anyway not necessary, this is equivalent: Name[] searchPath = Arrays.stream(dnsSearch).map(s -> Name.fromConstantString(s + "."))

nameserver 192.168.1.1
domain domain.com
search example.com dnsjava.org
options ndots:5
Copy link
Member

@ibauersachs ibauersachs Jun 3, 2019

Interesting. I wasn't aware there were this many options for resolv.conf. I wonder if we want to support some of them in the future (not for this PR, just a remark).

Copy link
Collaborator Author

@kingle kingle Jun 4, 2019

Logged issue #57

@ibauersachs ibauersachs merged commit 1f6bcc2 into dnsjava:master Jun 4, 2019
2 checks passed
@kingle kingle deleted the resolvconfig_initialtests branch Jun 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants