Loading...

Type: Sub-task
Resolution: Done
Priority: Minor
Fix Version/s: None
Affects Version/s: 2.0.30.Final
Component/s: Core
Labels:
None

Git Pull Request:
https://github.com/undertow-io/undertow/pull/910, https://github.com/undertow-io/undertow/pull/912

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.

is caused by: JDK-8237875 Loading...

Details

Description

Attachments

Issue Links

Easy Agile Planning Poker

Activity

People

Dates