Details
-
Sub-task
-
Resolution: Done
-
Minor
-
None
-
2.0.30.Final
-
None
Description
PathResourceManagerTestCase#testNonDefaultFileSystem fails with OpenJDK11.0.6:
19:33:39 Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T19:00:29Z) 19:33:39 Maven home: /qa/tools/opt/maven3-latest 19:33:39 Java version: 11.0.6, vendor: Oracle Corporation, runtime: /qa/tools/opt/x86_64/openjdk-11.0.6.10 19:33:39 Default locale: en_US, platform encoding: UTF-8 19:33:39 OS name: "linux", version: "3.10.0-1062.el7.x86_64", arch: "amd64", family: "unix"
and Adopt OpenJDK 11.0.6:
19:50:44 Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T19:00:29Z) 19:50:44 Maven home: /qa/tools/opt/maven3-latest 19:50:44 Java version: 11.0.6, vendor: Eclipse OpenJ9, runtime: /qa/tools/opt/x86_64/jdk-11.0.6+10_openj9-0.18.1 19:50:44 Default locale: en_US, platform encoding: UTF-8 19:50:44 OS name: "linux", version: "3.10.0-1062.el7.x86_64", arch: "amd64", family: "unix"
In case of Oracle JDK11.0.6, it fails only on RHEL6, not on RHE7 or RHEL8, neither on Windows Server 2012/2016. Not sure why, in this case.
Here is the test failure stacktrace on OpenJDK:
java.lang.AssertionError: expected:</dir/resource.txt> but was:</dir/./resource.txt> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:118) at org.junit.Assert.assertEquals(Assert.java:144) at io.undertow.server.handlers.file.PathResourceManagerTestCase.testNonDefaultFileSystem(PathResourceManagerTestCase.java:157) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:27) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55) at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137) at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107) at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83) at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75) at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344) at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
Very brief and quick look via debugger:
This assertion fails: Assert.assertEquals(resource.getFilePath(), list.get(0).getFilePath()); which leads us to this implementation of PathResource#list(). Here in debugger one can see that Paths returned by Files.newDirectoryStream(file) stream differs in JDK versions - in older releases, expected '/dir/resource.txt' path is given. In new releases the '/dir/./resource.txt' is given. This change in behaviour causes this test to fail.
I was able to track this JDK issue that is highly probably culprit of this problem https://bugs.openjdk.java.net/browse/JDK-8237875. TLDR version - some fixes from JDK12+ got into the JDK11.0.6. Based on the comments, these changes in behaviour will be probably reverted for JDK11 in the future, although, they will remain in JDK12+.
Thus we should take an action for new JDK releases (JDK12+) - either by fixing the test (java.nio.filePath#toRealPath() looks like a good candidate) or our implementation in Undertow.
Attachments
Issue Links
- is caused by
-
JDK-8237875 Loading...
