3
Q
[spring-projects/spring-boot]Jersey 的模板化请求可能会导致 URI 标签值爆炸
A
回答
7
这是一个古老的问题，我（过于乐观地）希望通过迁移到 Micrometer 来解决这个问题。
电表正在由 注册WebMvcMetricsFilter。考虑到该类的名称及其对 Spring MVC 的关注，这对于 Jersey 来说并没有什么意义。我认为我们应该更新过滤器，以便在可能的情况下，它只忽略 Spring MVC 未处理的请求。如果getHandler(HttpServletRequest)返回，也许我们可以对过滤器进行空操作null。如果我们想提供 Jersey 的指标，应该在单独的过滤器中完成。
8
谢谢， https://github.com/spring-projects/spring-boot/issues/5875#issuecomment-263294954中提供的 Bean解决了这个问题，但是看起来一点也不太好。
8
@wilkinsona 请注意，我们在 Micrometer 中通过该模块提供了完整的 Jersey 2 支持micrometer-jersey2，包括参数化的 URI 标记。最终，我们没有使用 servlet 过滤器来实现这一点，而是使用RequestEventListener.
我们只需要清理分流WebMvcMetricsFilterif Jersey 并在相关时自动配置 Jersey 支持。
5
@mikksoone 如果您的应用程序完全是 Jersey 2 而不是 Jersey 和 WebMVC 的混合，我认为现在足够的解决方法是禁用 webmvc 过滤器management.metrics.web.server.auto-time-requests=false，然后使用类似这样的内容配置 Jersey 集成。
9
@jkschneider 禁用management.metrics.web.server.auto-time-requests=false确实是禁用它，但是根据 micrometer-spring-legacy 配置 Jersey 并不能开箱即用（不再是了http.server.requests）。我正在使用 Spring Boot 2.0，提及它以防万一。
8
引用的 PR 自动配置 Jersey2 仪器。
@mikksoone 所经历的，它不是为 Spring-Boot 2 设置的。除此之外，通过吸引spring-boot-starter-hateos,spring-webmvc被默默地拉入，进而触发 WebMvc MetricsFilter 自动配置，以便http.server.requests存在未模板化的指标。
为了让仪器发挥作用，它需要出现在类路径中。 ( micrometer-jersey2)。也许当选择 Jersey 和 Actuator 时，start.spring.io 可以自动引入该依赖项？
可能的另一个问题：我在插入时观察到spring-boot-starter-hateos，执行器端点不再可达。 （2.0.1.BUILD-SNAPSHOT）我看到它们是通过 WebMvcEndpointHandlerMapping 注册的。当在仅包含 Jersey 的非混合环境中时，我看不到它们注册方式的任何输出。但他们是可以到达的。
我不熟悉有关此类混合网络环境设置的启动内部结构，也不熟悉spring-hateos其 Jersey 支持。
7
我在插入 spring-boot-starter-hateos 时观察到，执行器端点不再可达。 （2.0.1.BUILD-SNAPSHOT）我看到它们是通过 WebMvcEndpointHandlerMapping 注册的。
您能否为此打开一个单独的问题，并且最好提供一个小样本来重现您所描述的行为？
当在仅包含 Jersey 的非混合环境中时，我看不到它们注册方式的任何输出。但他们是可以到达的。
与 Spring MVC 和 WebFlux 不同，Jersey 不记录任何映射。在 2.0.1 快照中，我们开始记录 Web 公开端点的摘要，无论正在使用的 Web 框架如何（请参阅https://github.com/spring-projects/spring-boot/issues/12442）。
0
@wilkinsona我对混合设置进行了进一步的挖掘：当 webmvc 和 Jersey 都服务根（“/”）时 - 正如这里所发生的 - 执行器端点是 404。这仍然是一个错误吗？ （只是不想为已知的东西打开新问题。）一旦我移动 Jerseys 应用程序路径，事情就会再次开始工作。与 Spring-Boot 1.5 的行为相同。所以这个不幸的星座在spring-webmvc潜入时并没有行为上的改变。
3
这仍然属于错误吗？
不，我不这么认为。当您并排使用 Jersey 和 MVC 时，我们的期望是它们将被配置为共存，方法是将它们移动到单独的路径，或者使用 Jersey 过滤器并将其配置为允许请求在请求继续时继续。 404。
0
感谢你的回答。相关 PR 是否有机会进入2.0.1？也将帮助那些从 SB 1.5 更新micrometer-spring-legacy并进行设置的人。micrometer-jersey2
7
今天我们花了一些时间讨论这个问题并得出了一些结论：
当前的指标过滤器包含通用逻辑和 MVC 特定逻辑的组合。我们希望它只关注一般逻辑，然后委托给策略接口的实现来获取特定于特定 Web 堆栈的信息（https://github.com/spring-projects/spring-boot/issues/ 13064）。此更改必须等待 2.1，这意味着我们不会接受当前形式的 #12482，也不会将其合并到 2.0.x 中。
我们仍然需要在 2.0.x 中做一些事情，我们将使用这个问题来做到这一点。我们当前的计划是取消使用 URI 路径信息的后备方案。
4
我看不到 OP 问题在哪里得到解决。无意冒犯，但此问题已从“缺少自动配置的 jersey2 检测”降级为“调低 WebMVC MetricsFilter 以通过将未知请求分流到常见标记值来修复指标爆炸”。如果我可以这么说的话，当前的修复是一个很好的修复。别误会我的意思。
同时，有两个 PR 正在解决这个问题。众所周知，我们需要照顾 WebMVC MetricsFilter 以免干扰。 （要么将其关闭，要么将 Jersey-Filter 挂在其前面。至少后者是我在 1.5 中测试时所做的。）
再次强调，无意冒犯。我知道您必须处理大量问题，并且需要在解决问题和推迟或拒绝问题之间找到一条良好的途径。
我认为#13064 是真正的工作应该完成的地方？计划实现哪个里程碑？
8
我认为#13064 是真正的工作应该完成的地方？
正确，以及类似于 #12482 的内容，但针对提议的新方法进行了重新设计。
计划实现哪个里程碑？
它被分配给积压工作，如此处所述，用于解决我们希望在 2.1 中解决的问题。
2
我看不到 OP 问题在哪里得到解决
我还应该指出，OP 是 Micrometer 项目的领导者，并且已经给出了？对我们提议的行动方针的反应。
5
我还应该指出，OP 是 Micrometer 项目的领导者，并对我们提议的行动方案给出了 +1 反应。
我指的是所引用问题的“OP 内容”以及此处的评论，其中澄清了缺少内容的情况（jersey2 仪器设置）以及导致所见内容的原因（webmvc 指标过滤器为球衣路径生成指标）。是的，我在千分尺项目合作时与乔恩接触并不是不可能的:)
都好！感谢您的回复！