tree 6661d70fbb0453ddf07299aaf7a4d507bece77b4
parent 8794f8001fc716184cd13c354049a41100067dcd
author 吴晟 Wu Sheng <wu.sheng@foxmail.com> 1787993251 +0800
committer GitHub <noreply@github.com> 1787993251 +0800
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJqkpyjCRC1aQ7uu5UhlAAAtq0QAHfaEs6tpKfr7Q6UVe9/1kd6
 r6FptIHD+4Czf14r+smkwOw7m40KamCMTQ5ldYFN+YUHvOCPP7kmAGlC64V0a3un
 Vo5BwFwlqi1byK1n5Wgo7dpl6dd99wtYxhFwAokFU3aPQi3YdU1whN0OXFgmjCbO
 RICqyozmTiSbKmjgVXCOIkMIqFjNTpQYa+Ahx8TI8yRoUEsla1yJ+MlTOt4EWqAu
 yNZLe6+tlCJ0E7XxlO+crRIx0RV5wOUE3rQVLBOa0vYdh2l/pf0VCBsArk+etzt7
 i7zwmljShwCx9gSeh5xR+B//7vFPLV5pI2zxfRvZIpThXDzKeffWIii9YbET7xVg
 zlTBbHn9L1+yWPO05aYh00Avr/BHSJ0XzEFlqIlj2e4wSKs5FXNA0k8ATz+ojAbC
 VX94WK8MGQyvr1EsrzY7VuoUwklVk1oANx4muqp2ocOj54GtE4xcAXj/mUb+oqOR
 zNRm4IYu7uvPFxLv80KANmgiePw7yI35ZScCP/ETWKTb7sLDHotrjR0qb4z7u42b
 0RpwUg5Sihpcb/ZTrLGfoZ2LVEIyg6CF96GJKkkFuvqoMmj8Llz6D/HLaLuybxJr
 klI0GFucK17Go4766BnzDS/zjcV1n5mfha5I16kG7p+NYPHaK/45JxvMFqd01nNZ
 J1W6Ce2zHBwgzXW02wIt
 =M4yo
 -----END PGP SIGNATURE-----
 

Support Spring Framework 7 (Spring Boot 4) and Spring Cloud Gateway 5.x (#826)

* Support Spring Framework 7 (Spring Boot 4) and Spring Cloud Gateway 5.x

Spring Framework 7.0 dropped the MultiValueMap contract from HttpHeaders
(spring-projects/spring-framework gh-33913), removing List get(Object). The
webflux-6.x plugin was compiled against that overload, so every request through
DispatcherHandler#handle threw NoSuchMethodError before the entry span was
created: the service kept serving traffic but produced no traces at all.
spring-cloud-gateway-4.x shades a byte-identical copy of that interceptor and
its witness class still resolves on Spring Cloud Gateway 5.x, so gateway users
hit it through the documented plugin as well.

A bytecode sweep of every built plugin jar, resolving all org/springframework
constant-pool refs against spring-web/webflux 5.3.39, 6.2.0 and 7.0.5, found
only two Spring 7 removals reaching the agent, across three call sites.

- spring-webflux-6.x / -5.x: read the header via HttpHeaders#getFirst(String),
  which is declared on HttpHeaders itself in Spring 5, 6 and 7 with the same
  descriptor. Note HttpHeaders#get(String) does NOT work: compiled against
  Spring 6 javac still emits the (Object) descriptor. getOrEmpty is not
  cross-version safe either, its descriptor changes between 6 and 7.
- mvc-annotation-commons RequestUtil: use getValuesAsList(String). getFirst is
  wrong here because this site consumes every value. Note it additionally
  splits comma-delimited values.
- mvc-annotation-commons AbstractMethodInterceptor: drop the premature reactive
  status read. ServerHttpResponse#getRawStatusCode() was removed in Spring 7,
  and it ran before the response was written so it normally read null anyway.
  The version-specific InvokeInterceptor already sets http.status_code in
  Mono#doFinally, once the status is actually known.

Add Spring generation witnesses to both webflux plugins. The only guard was
WitnessMethod(Mono, contextWrite), which bounds Reactor and not Spring, which
is why the plugin attached to Spring 7 and then failed on every request rather
than cleanly not attaching. On Reactor 3.4 both Mono#subscriberContext and
Mono#contextWrite exist, so the 5.x and 6.x plugins would both match
DispatcherHandler#handle on Spring Boot 2.4-2.7.

Split the WebFlux application toolkit. Reactor removed Signal#getContext() in
3.5.0 and ContextView does not exist before 3.4.0, so no single artifact can
serve both; continueTracing has been broken on all of Spring Boot 3 and 4 since
Nov 2022. apm-toolkit-webflux becomes apm-toolkit-webflux-5.x (package
...toolkit.webflux.v5, unchanged behaviour) and a new apm-toolkit-webflux-6.x
(package ...toolkit.webflux.v6) compiles against Reactor 3.5 and uses
Signal#getContextView(). Compiling forward is deliberate: the module rotted
silently for three years because it compiled against the oldest Reactor, so
javac never flagged the removal. Distinct packages make picking the wrong
artifact a compile error rather than a runtime NoSuchMethodError. The
activation keeps matching the legacy un-versioned names, so applications that
never upgrade their toolkit still work against a newer agent.

No plugin, framework version or Reactor version loses support.

Add webflux-6.x-7.x-scenario (Spring Boot 3.0 -> 4.1, one version per minor)
and gateway-5.x-scenario (Spring Cloud Gateway 5.0.3 on Spring Boot 4). Both
drive a full round-trip so the cross-process ref is asserted, which is the only
thing that proves the sw8 header is read back correctly.

Closes apache/skywalking#14047