* [maven-release-plugin] prepare release v8.15.0
* [maven-release-plugin] prepare for next development iteration
* Create changes-8.15.0.md
* Set changes.md for 8.16.0
* fix: Fix MultiScopesAnalysisListener#setPublicAttrs log warn frequently. #6562
1. Rename current STATUS_CODE to HTTP_RESPONSE_STATUS_CODE, real tag key should be http.status_code.
2. Add a new string tag RPC_RESPONSE_STATUS_CODE to hold all string type value tag. The key is `rpc.status_code`.
3. At the backend, keep responseCode for HTTP_RESPONSE_STATUS_CODE tag, but add @Deprecated. Also, add httpResponseStatusCode(a duplicate of responseCode) and rpcStatusCode(for RPC_RESPONSE_STATUS_CODE) fields for OAL.
* Modify `Tags.STATUS_CODE` field name to `Tags.HTTP_RESPONSE_STATUS_CODE` and type from `StringTag` to `IntegerTag`, add `Tags.RPC_RESPONSE_STATUS_CODE` field to hold rpc response code value.
* Add `rpcStatusCode` for `rpc.status_code` tag in the OAL objects. The `responseCode` field is marked as deprecated and replaced by `httpResponseStatusCode` field.
* Tag `status_code` is still supported in the backend for forward compatbility. Will be removed one year later.
Co-authored-by: 吴晟 Wu Sheng <wu.sheng@foxmail.com>
When there is a fallback in webflux (like a hystrix fallback or a webflux fallback method that involves visiting a new URL). This interceptor would be invoked twice, one for origin request and another for fallback request. The ServerWebExchange for these two aren't exactly the same one, but the former one is a delegate inside of the latter one, thus, they share the same attributes.
The problem of the old code is that get the span from attributes within the execution of Mono would get span for the latter request twice. so just move this part of code out could solve the problem.
It seems impossible to make the mono chain work like expected. So add a check about whether the best matching pattern really matches the URL. This check code is how webflux generating the best match pattern,
吴晟 Wu Sheng
Chen Ziyan
Zimmem
wankai123
wallezhang
yujiaxinlong
kezhenxu94
Xin,Zhang
cyejing