这通过添加ServerProperties.Tomcat条目修复了#13613 server.tomcat.is-web-resource-caching-allowed。反过来，这会在 tomcat 上设置WebResourceRootvalue isCachingAllowed。这实质上关闭了 Tomcat 执行的 WebResource 文件级缓存机制。一般来说，这是一个可配置的选项，我想将其公开为可配置的application.properties。
这对我来说看起来是一个很好的补充。我可能会建议使用不同的属性名称，因为is-前缀会导致设置器稍微不寻常。也许我们应该使用类似的东西server.tomcat.webresource.allow-caching？如果我们想要公开webresource诸如setCacheTtl.
同意前缀is，我在想server.tomcat.use-webresource-caching，但忘了添加它（那里有什么想法？）。不知道我是否想使用webresource属性块，因为它更多地摆弄网络EmbeddedTomcatContext资源而不是网络资源。我将更改is-> use。如果您还有其他想法，请告诉我。我不确定我是否在“正确”的地方进行了集成，但我确实知道它是有效的。
嵌套属性+1 webresource。它反映了设置属性的类型，并为我们将来提供其他与资源相关的属性进行分组。
我们应该使用 war 打包来验证行为，因为我们已经在这种情况下自定义了资源根来隐藏加载器类。
好吧，团体共识获胜。我会朝那个方向前进。我会在今天下午（UTC-4）尝试继续进行，因为我目前处于 AFK 状态。并且，总的来说，非常感谢您愉快的讨论/贡献范例。
（请原谅那里的构建失败，将解决该问题。）
我认为最后一次提交完成了我们在这里的目标，是吗？ @wilkinsona - 通过“使用 war 打包验证行为”，您的意思是.war在 tomcat 容器内运行文件吗？我不太熟悉将引导作为战争的机制。如果你指出如何测试它的方向，我就会开始研究它。
（当你们认为我们已经准备好合并时，还计划压缩提交。）
@philwebb - 我现在应该继续压缩提交吗？
@chtompki 不，不用担心。当我们为合并变基时我们会这样做。
这是我们需要仔细检查的代码。我认为这会很好，但要确保一种定制不会践踏另一种定制。
明白了。我将在一个使用本地构建的 2.1.0-SNAPSHOT 的简单项目中进行探索，看看是否可以看到两个不同位置之间的相互作用。此外，是否值得将这两种定制放在同一个地方以确保更好的可维护性？
合并此属性时，我们应确保使用新属性更新附录。
@snicoll - 这里是“附录”：https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-docs/src/main/asciidoc/appendix-应用程序属性.adoc？如果是这样，我会将其添加到拉取请求中。
是的，谢谢。
好奇在我们等待积压的过程中，您是否认为我还有其他事情要做？
@chtompki 我认为我们很好，谢谢。除非您想将该属性重命名为allow-caching您use-caching当前提议的名称。我认为前者更适合正在设置的底层 Tomcat 属性。如果没有，不用担心，当我们开始合并时，我们可以解决它。
结果我们已经有了一个resource实际配置 TTL 缓存的部分，因此我已将属性移至此处，并使用相同的代码路径简化了定制器。
@chtompki 非常感谢您对 Spring Boot 的第一个贡献。现在已合并到master