On Thu, Oct 15, 2015 at 2:32 PM, Lucas Theisen <[email protected]>
wrote:

> On Thu, Oct 15, 2015 at 1:57 PM, Stefan Seelmann <[email protected]>
> wrote:
>
>> On 10/15/2015 07:44 PM, Stefan Seelmann wrote:
>> > On 10/15/2015 07:26 PM, Lucas Theisen wrote:
>> >>
>> >> I tried both Oracle jdk1.8.0_60 and openjdk-1.7.0.71, so i don't think
>> it
>> >> has to do with java version.  I tried turning off firewalld, but no
>> dice.
>> >> Could be SELinux, i could try booting without...
>> >>
>> >
>> > Lucas,
>> >
>> > What is the output of `nslookup localhost`?
>> > And is locahost in your /etc/hosts?
>> >
>>
>> So in [1] we see the code that starts the forked JVM. It also starts a
>> RMI LocateRegistry, I think on localhost.
>>
>> Then the forked process should also try to connect to that registry,
>>
>> Here [2] [3] are some other examples where connection to RMI registry
>> failed.
>>
>> HTH,
>> Stefan
>>
>> [1]
>>
>> https://github.com/ops4j/org.ops4j.pax.exam2/blob/25d5181a00b2e433537e4b53dce50b8925236bc3/containers/pax-exam-container-forked/src/main/java/org/ops4j/pax/exam/forked/ForkedFrameworkFactory.java#L103
>> [2]
>> https://stackoverflow.com/questions/6180383/rmi-registry-connecting-to-wrong-adress
>> [3]
>> http://knowledgebase.progress.com/articles/Article/AdminServerattemptstobindtothewrongIPAddress
>>
>
> Soooooo.  Thanks Stefan, the stackoverflow solution pointed out that the
> RMI registry gets the the hostname as follows:
>
> java.net.InetAddress.getLocalHost().getHostAddress();
>
> And from the javadoc [1]:
>
> Returns the address of the local host. This is achieved by retrieving
>  the name of the host from the system, then resolving that name into
>  an InetAddress.
>
> The key part here is the "resolving that name".  At the top of the javadoc
> page for InetAddress in the general comments we see:
>
> Host name-to-IP address resolution is accomplished through
>  the use of a combination of local machine configuration information
>  and network naming services such as the Domain Name System (DNS)
>  and Network Information Service(NIS).
>
> This means that if you are using a machine whose "name of the host from
> the system" is NOT registered by name in the "local machine configuration"
> then it will attempt to look it up on a "network naming service".  If, like
> me, your name is not registered in your configured "network naming
> service", then the behavior is undefined.  In my case it was getting
> redirected by my ISP (Verizon FIOS), who sends any name it cannot resolve
> to the Non Existent Domain provider "barefruit" with IP address
> 92.242.140.21.  This is then used as the IP address of localhost rather
> than the loopback interface.  This seems like a really dangerous way to run
> unit tests...  It seems like bad behavior all around.  First, the DNS
> server resolving that way is COMPLETELY wrong, but they love their
> advertisement.  Second, java's getLocalHost() method not confirming that
> the IP resolution from the "network naming service" is an IP of a local
> interface (after all, the method is NAMED getLocalHost).  And, third, using
> getLocalHost() with this being the behavior is inherently dangerous (as
> request to connect to a service you think is on your localhost is getting
> sent somewhere else).
>
> Anyway, I can resolve this build issue by adding my hostname to
> /etc/hosts, but we should probably consider switching away from using
> InetAddress.getLocalHost().
>
> Lucas
>


On a side note, i submitted a bug to the PAX folks [1] to avoid using
getLocalHost().

Also, I finished the build succesfully, so:

+1 for release.

[1]https://ops4j1.jira.com/browse/PAXEXAM-740

Reply via email to