will

Hi @JohnNiang ，是否可以像下面这样优化一下 OptimisticLockingFailureException 这个异常的日志级别，使得用户不会刻意关注到它，如果可以的话我很乐意提一个 PR 来解决它。 ``` } catch (Throwable t) { if (t instanceof OptimisticLockingFailureException) { log.debug( "Optimistic locking failure when reconciling request: {}", t.getMessage()); } else {...

/assign

感谢你们用心的努力工作，创造了这么好的产品。 /点赞 /点赞 /点赞 666 666

这里是符合预期的，在插件禁用后则不存在此服务接口。 需要在前端根据插件状态，已禁用则不所有设置类 tab，也就没有了这次404的请求。

主题也存在此情况

2.0.1修复成功，验证通过，禁用后没有了404请求。

嗯，文档说明可以到插件提供方的网站里面看到。

通过插件的形式好还是核心系统里面包含的形式好些呢？

嗯嗯 目前情况来看在这里添加一个关于菜单还比较合适

感觉有点不妥当，`actuator`接口一般都用来做内部系统间通讯了，有可能出现鉴权体系跟本系统管理后台不同的情况，比如当在`kubernetes`环境下拿来给 `k8s` 用了，这时候没有鉴权，如果管理后台也用了这个 `actuator` 接口，那就成了一个开放接口，暴露系统信息在安全层面不太妥当。有没有更好的方案可以搞定？可否考虑新开一个系统管理员级别的接口出来如 `/api/system/probe` 这种呢？