1. 首页
  2. 问答
  3. [spring-projects/spring-boot]通过工具链运行测试时允许使用额外的 JVM 参数

[spring-projects/spring-boot]通过工具链运行测试时允许使用额外的 JVM 参数

2024-06-26 297 views
1

你好，

这是整个 Java 17 故事 #26767 的一部分，是针对第 6 点和第 7 点的解决方案，我们访问内部以重置状态（URL.factory在 Servlet 测试中清除）或创建测试场景（设置xdostime）ZipEntry，并且没有其他方法可以修复这些问题（除了为 JDK 17 禁用它们）

  1. 与 5 类似的问题，但在 AbstractServletWebServerFactoryTests.tearDown() 中 - 可能与打开模块的解决方案类似
  2. JarFileTests.jarFileEntryWithEpochTimeOfZeroShouldNotFail() 失败，因为它尝试在 ZipEntry 上设置 xdostime，而 ZipEntry 是内部的。我们可以针对 JDK 17 及更高版本禁用该测试，或者再次尝试打开模块。

这个想法是ToolchainExtension使用一个新属性来扩展，该属性设置任务的 JVM 参数Test（如果给定）。我将其设计为灵活的，因此可以传递任何类型的 JVM 参数，而不仅仅是提供一种打开模块的方法。

在此过程中，我还删除了--illegal-access=warn对 Java 17 没有影响的。如果您希望我保留它，我可以将其保留在较低版本上，但实际上它只会在 Java 16 管道上设置，因为这是目前唯一基于工具链的构建。一旦我们有了 17 的管道，16 的管道很可能会消失。

请告诉我你的想法。干杯，克里斯托弗

dreis2211

回答

3

ZipEntry 定义了 setLastModifiedTime、setTimeLocal 等方法，为什么需要 hack xdostime 字段呢？

AlanBateman

0

@AlanBateman 如果我没记错的话，有些 JAR 的创建时间为 0（1970 年），这不在 DOS 时间范围内，Boot 中的一个错误无法读取CentralDirectoryFileHeader.java#L119中的时间。请参阅#19518。

如果我理解正确的话，手头的测试试图模仿这一点。它实际上已经调用了，setLastModifiedTime但仅凭这一点并不能帮助覆盖该场景，因为读入的是 DOS 时间CentralDirectoryFileHeader，而 Java 方法不允许在此处将内容设置为 0。不过，也许作为测试的创建者的 @mbhave 对此有更多见解。

dreis2211

8

让我看看我是否可以在不反射的情况下写出时间，但我想将其与 PR 分开……我实际上看到 JDK 本身中的一些测试试图涵盖类似的场景。

dreis2211

5

@AlanBateman 感谢您询问这个问题。

@dreis2211 FWIW，我相信您对该测试的理解是正确的。

如果真的需要，我认为我们可以通过签入适当配置的 jar 文件而不是将其作为测试的一部分来避免使用反射。不过，如果可能的话，能够坚持使用生成方法会很好。

wilkinsona

6

spring-boot-loader我打开了#27100 来以不同方式解决 JarFileTests 问题，并从此 PR 的 build.gradle中恢复了附加参数。

dreis2211

8

结束并赞成 #27100

philwebb

1

@philwebb #27100 不是对整个 PR 的替换，只是对我已经回滚的 spring-boot-loader 包的一部分的替换。其他更改仍需进行。

dreis2211

2

哎呀。很抱歉。

philwebb

6

@philwebb 我对 merge-with-amendments 标签感到疑惑。如果您想要更改某些内容，请告诉我，我会这样做以节省您的时间。

dreis2211

2

@AlanBateman 既然你已经在这里，是否有URL.factory我不知道的重置的可能性？

dreis2211

3

@AlanBateman 既然你已经在这里，是否有URL.factory我不知道的重置的可能性？

Java 9 引入了 URLStreamHandlerProvider，以便能够使用其他 URL 流处理程序实现来部署提供程序，这避免了在某些情况下使用 setURLStreamHandlerFactory 的需要。我不知道这是否有帮助。如果没有，您可以在 OpenJDK net-dev 邮件列表中开始讨论并概述需求吗？

AlanBateman

4

我想，将基线提高到 11（无论何时实现）可能会为将来以不同的方式解决这个问题提供可能性。目前，当前的解决方案似乎是最务实的做法。

dreis2211

9

非常感谢，@dreis2211。

wilkinsona