不同的执行器(管理服务器)端口改变 HTTP 响应
Different actuator (management server) port changes HTTP response
我在 Chaos Monkey For Spring Boot 中遇到了困难,当用户 POST 无效时(比如 {"level": -2}
通过 REST 更新到我们的执行器端点时的错误响应可以更新 CMSB 行为的选项(只允许正水平)。在第一张图片中,我将 management.server.port
设置为 8888
,将应用程序端口设置为 8080
。发布时新 属性 到 CMSB REST API 我收到以下响应(这不是我们所期望的):
如果我将管理端口保留在与应用程序相同的端口,我将收到以下响应:
对于这两种情况,我们都希望得到相同的错误响应(第二个)。所以我们问我们(在 CMSB)这是否是 spring 引导的预期行为,如果不是,我们的选择是什么来绕过编写我们自己的错误响应处理程序,以防管理端口与应用程序不同港口。
请注意,这与 spring 引导的 chaos monkey 的预期行为无关,而是关于这是否是 spring 引导错误。在这两种情况下,我们都希望有详细的错误响应,以便用户知道出了什么问题。在幕后,我们使用 @Validated
注释结合类似这样的东西来验证输入:
@Data
@NoArgsConstructor
@Validated
@JsonInclude(JsonInclude.Include.NON_NULL)
public class AssaultPropertiesUpdate {
@Nullable
@Min(value = 1)
@Max(value = 10000)
private Integer level;
附带说明:在这两种情况下,日志中的错误消息都是正确的。但是只有第二种情况是这个错误信息
WARN 4477 --- [nio-8080-exec-1] .w.s.m.s.DefaultHandlerExceptionResolver : Resolved [org.springframework.web.bind.MethodArgumentNotValidException: Validation failed for argument [0] in public org.springframework.http.ResponseEntity<?> de.codecentric.spring.boot.chaos.monkey.endpoints.ChaosMonkeyRestEndpoint.updateAssaultProperties(de.codecentric.spring.boot.chaos.monkey.endpoints.AssaultPropertiesUpdate): [Field error in object 'assaultPropertiesUpdate' on field 'level': rejected value [-2]; codes [Min.assaultPropertiesUpdate.level,Min.level,Min.java.lang.Integer,Min]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [assaultPropertiesUpdate.level,level]; arguments []; default message [level],1]; default message [must be greater than or equal to 1]] ]
用作响应负载。
最小示例项目:https://github.com/fletchgqc/mediator
使用 mvn spring-boot:run
启动项目。然后使用负载 {"level": -2}
针对 http://localhost:8080/actuator/chaosmonkey/assaults
执行 POST。应显示正确的错误响应(如图 2 所示)。
然后停止项目,向https://github.com/fletchgqc/mediator/blob/master/src/main/resources/application.properties 添加management.server.port=8888
并再次启动应用程序。使用与之前相同的负载对 http://localhost:8888/actuator/chaosmonkey/assaults
执行 POST。应该会出现错误的错误消息(如图 1 所示)。
看起来 spring 团队在此处修复了它:https://github.com/spring-projects/spring-boot/issues/21036
我在 Chaos Monkey For Spring Boot 中遇到了困难,当用户 POST 无效时(比如 {"level": -2}
通过 REST 更新到我们的执行器端点时的错误响应可以更新 CMSB 行为的选项(只允许正水平)。在第一张图片中,我将 management.server.port
设置为 8888
,将应用程序端口设置为 8080
。发布时新 属性 到 CMSB REST API 我收到以下响应(这不是我们所期望的):
如果我将管理端口保留在与应用程序相同的端口,我将收到以下响应:
对于这两种情况,我们都希望得到相同的错误响应(第二个)。所以我们问我们(在 CMSB)这是否是 spring 引导的预期行为,如果不是,我们的选择是什么来绕过编写我们自己的错误响应处理程序,以防管理端口与应用程序不同港口。
请注意,这与 spring 引导的 chaos monkey 的预期行为无关,而是关于这是否是 spring 引导错误。在这两种情况下,我们都希望有详细的错误响应,以便用户知道出了什么问题。在幕后,我们使用 @Validated
注释结合类似这样的东西来验证输入:
@Data
@NoArgsConstructor
@Validated
@JsonInclude(JsonInclude.Include.NON_NULL)
public class AssaultPropertiesUpdate {
@Nullable
@Min(value = 1)
@Max(value = 10000)
private Integer level;
附带说明:在这两种情况下,日志中的错误消息都是正确的。但是只有第二种情况是这个错误信息
WARN 4477 --- [nio-8080-exec-1] .w.s.m.s.DefaultHandlerExceptionResolver : Resolved [org.springframework.web.bind.MethodArgumentNotValidException: Validation failed for argument [0] in public org.springframework.http.ResponseEntity<?> de.codecentric.spring.boot.chaos.monkey.endpoints.ChaosMonkeyRestEndpoint.updateAssaultProperties(de.codecentric.spring.boot.chaos.monkey.endpoints.AssaultPropertiesUpdate): [Field error in object 'assaultPropertiesUpdate' on field 'level': rejected value [-2]; codes [Min.assaultPropertiesUpdate.level,Min.level,Min.java.lang.Integer,Min]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [assaultPropertiesUpdate.level,level]; arguments []; default message [level],1]; default message [must be greater than or equal to 1]] ]
用作响应负载。
最小示例项目:https://github.com/fletchgqc/mediator
使用 mvn spring-boot:run
启动项目。然后使用负载 {"level": -2}
针对 http://localhost:8080/actuator/chaosmonkey/assaults
执行 POST。应显示正确的错误响应(如图 2 所示)。
然后停止项目,向https://github.com/fletchgqc/mediator/blob/master/src/main/resources/application.properties 添加management.server.port=8888
并再次启动应用程序。使用与之前相同的负载对 http://localhost:8888/actuator/chaosmonkey/assaults
执行 POST。应该会出现错误的错误消息(如图 1 所示)。
看起来 spring 团队在此处修复了它:https://github.com/spring-projects/spring-boot/issues/21036