FYI: today is the first time i've looked at this test before, so take all of my comments with a grain of salt...
why is it trying to resolve the host? Is it so that it can then try to connect to it and the test expects that this will fail?
From what i can tell, nothing in the test, that i can see, is trying to resolve the hostname or IP or connect to any of these URLs. A "MockPageFetcher" is explicitly plugged into the SimplePostTool when used in the test to mock out the HTTP communication to prevent this.
The problem (again: as far as i can tell) is entirely because the tests (and underlying code in SimplePostTool) use the java.net.URL class, which can/will attempt hostname resolution of DNS names used in URLs under the covers in some cases – notable anytime the URL.equals() or URL.hashCode methods are called.
use ips like [ff01::114] instead.
I've got no problem doing that if you think it makes a diff – but just so i understand: can you explain why that is better then 127.42.42.42 ?
if you really just need a URL, why not use file://....
That might work, but the SimplePostTool actually supports diff options for dealing with local files vs remote web urls, and the test's MockPageFetcher actually simulates servers that response with diff HTTP status codes, so i'm not sure if using "file://" will work and/or test the same things.
attaching an updated patch using "[ff01::114]" instead of "127.42.42.42" per rmuir's request.
Shai Erera: does this still run "fast" for you?
any objections from anyone to be committing this?