Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
3.0.0-M5
-
None
-
$ mvn -version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Develop\some-project\middleware\_develop\maven\default
Java version: 11.0.7, vendor: AdoptOpenJDK, runtime: C:\Develop\some-project\middleware\_develop\java\default
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"$ mvn -version Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: C:\Develop\some-project\middleware\_develop\maven\default Java version: 11.0.7, vendor: AdoptOpenJDK, runtime: C:\Develop\some-project\middleware\_develop\java\default Default locale: de_DE, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Description
I was really looking forward to the new TCP process communication (thanks for that!) but it seems it has a fundamental issue in non-trivial network setups:
After adding:
<forkNode implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>
my test executions are getting stuck at:
[INFO] ------------------------------------------------------- [INFO] T E S T S [INFO] -------------------------------------------------------
-X reveals:
[INFO] ------------------------------------------------------- [INFO] T E S T S [INFO] ------------------------------------------------------- [DEBUG] Determined Maven Process ID 15428 [DEBUG] Fork Channel [1] connection string 'tcp://192.168.99.1:51401' for the implementation class org.apache.maven.plugin.surefire.extensions.SurefireForkChannel [DEBUG] boot classpath: [omitted] [DEBUG] boot(compact) classpath: [omitted] [DEBUG] Forking command line: cmd.exe /X /C "C:\Develop\some-project\middleware\_develop\java\default\bin\java -jar C:\Develop\Temp\surefire2701709940583667253\surefirebooter12465325576730119938.jar C:\Develop\Temp\surefire2701709940583667253 2020-06-18T17-33-41_288-jvmRun1 surefire6381289732609561853tmp surefire_02272472648642066547tmp"
The problem here is that 192.168.99.1 is a IP of one of my VirtualBox Host-Only network adapters. So that won't work.
From my naive perspective, I would have expected 127.0.0.1.
I debugged the constructor of SurefireForkChannel and there Inet4Address.getLocalHost() is returning the wrong IP.
At this point I am asking myself why SurefireForkChannel isn't simply using InetAddress.getLoopbackAddress() (which returns 127.0.0.1)?
Alternatively a bindAddress parameter would come in handy.
Attachments
Issue Links
- is duplicated by
-
SUREFIRE-1805 New config `bindAddress` and `connectionAddress` in SurefireForkNodeFactory
- Closed
- relates to
-
SUREFIRE-1805 New config `bindAddress` and `connectionAddress` in SurefireForkNodeFactory
- Closed
- links to