webflux-6.x-plugin throws NoSuchMethodError on Spring Framework 7 (Spring Boot 4) — no webflux-7.x plugin available

[Tonylion2025]

What happened?

When deploying a Spring Cloud Gateway application built on Spring Boot 4.0.3 (Spring Framework 7.x) with SkyWalking Java Agent 9.7.0, the agent fails to instrument WebFlux endpoints and throws a NoSuchMethodError at runtime:

ERROR 2026-08-28 08:43:15.341 reactor-http-nio-3 InstMethodsInter : class[class org.springframework.web.reactive.DispatcherHandler] before method[handle] intercept failure 
java.lang.NoSuchMethodError: 'java.util.List org.springframework.http.HttpHeaders.get(java.lang.Object)'
	at org.apache.skywalking.apm.plugin.spring.webflux.v6.DispatcherHandlerHandleMethodInterceptor.beforeMethod(DispatcherHandlerHandleMethodInterceptor.java:59)
	at org.apache.skywalking.apm.agent.core.plugin.interceptor.enhance.InstMethodsInter.intercept(InstMethodsInter.java:83)
	at org.springframework.web.reactive.DispatcherHandler.handle(DispatcherHandler.java)
	at org.springframework.web.server.handler.DefaultWebFilterChain.lambda$filter$0(DefaultWebFilterChain.java:107)
	at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:46)
	at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:75)
	at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:54)
	at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:75)
	at reactor.core.publisher.MonoTapRestoringThreadLocals.subscribe(MonoTapRestoringThreadLocals.java:78)
	at reactor.core.publisher.Mono.subscribe(Mono.java:4569)
	at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.subscribeNext(MonoIgnoreThen.java:268)
	at reactor.core.publisher.MonoIgnoreThen.subscribe(MonoIgnoreThen.java:51)
	at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:75)
	at reactor.core.publisher.MonoDeferContextual.subscribe(MonoDeferContextual.java:56)
	at reactor.netty.http.server.HttpServer$HttpServerHandle.onStateChange(HttpServer.java:1378)
	at reactor.netty.ReactorNetty$CompositeConnectionObserver.onStateChange(ReactorNetty.java:730)
	at reactor.netty.transport.ServerTransport$ChildObserver.onStateChange(ServerTransport.java:529)
	at reactor.netty.http.server.HttpServerOperations.handleDefaultHttpRequest(HttpServerOperations.java:870)
	at reactor.netty.http.server.HttpServerOperations.onInboundNext(HttpServerOperations.java:796)
	at reactor.netty.channel.ChannelOperationsHandler.channelRead(ChannelOperationsHandler.java:115)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at reactor.netty.http.server.HttpTrafficHandler.channelRead(HttpTrafficHandler.java:282)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:355)
	at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:434)
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:361)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:325)
	at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:249)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:355)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1429)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:918)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:176)
	at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.handle(AbstractNioChannel.java:445)
	at io.netty.channel.nio.NioIoHandler$DefaultNioRegistration.handle(NioIoHandler.java:388)
	at io.netty.channel.nio.NioIoHandler.processSelectedKey(NioIoHandler.java:596)
	at io.netty.channel.nio.NioIoHandler.processSelectedKeysOptimized(NioIoHandler.java:571)
	at io.netty.channel.nio.NioIoHandler.processSelectedKeys(NioIoHandler.java:512)
	at io.netty.channel.nio.NioIoHandler.run(NioIoHandler.java:484)
	at io.netty.channel.SingleThreadIoEventLoop.runIo(SingleThreadIoEventLoop.java:225)
	at io.netty.channel.SingleThreadIoEventLoop.run(SingleThreadIoEventLoop.java:196)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:1195)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:1583)

The gateway service produces zero traces in SkyWalking UI — no entry spans, no topology node, completely invisible.

[wu-sheng]

Confirmed, and thanks for the precise stack trace — this is an agent bug, not your configuration. Fix is up as apache/skywalking-java#826.

Root cause

Spring Framework 7.0 dropped the MultiValueMap contract from HttpHeaders (spring gh-33913), which removed the List get(Object) overload:

spring-web 6.2.19  public class HttpHeaders implements MultiValueMap<String,String>, Serializable
                   public java.util.List<java.lang.String> get(java.lang.Object);
spring-web 7.0.x   public class HttpHeaders implements java.io.Serializable
                   public java.util.List<java.lang.String> get(java.lang.String);   // only

DispatcherHandlerHandleMethodInterceptor:59 was compiled against the removed overload, so it emits invokevirtual HttpHeaders.get:(Ljava/lang/Object;)Ljava/util/List; — byte-for-byte the method your NoSuchMethodError names. The boundary is exact: all of spring-web 6.2.x is fine, every 7.x breaks, and Spring Boot 4.0.3 pins Spring Framework 7.0.5.

Your "zero traces" observation is the expected consequence, not a second problem: InstMethodsInter catches the error and still calls through, so your gateway keeps serving traffic normally — but the entry span is created four lines after the throw, so it never exists. Hence one ERROR per request and nothing in the UI.

One thing worth flagging that isn't obvious from your report: this is not limited to people who enabled the WebFlux plugin. spring-cloud-gateway-4.x-plugin shades a byte-identical copy of that interceptor, and its witness class still resolves on Spring Cloud Gateway 5.x — so a user who copies only the documented gateway plugin hits exactly the same failure.

What we fixed

A bytecode sweep of every plugin jar, resolving all org.springframework references 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 with HttpHeaders#getFirst(String), which is declared on HttpHeaders itself in Spring 5, 6 and 7 with an identical descriptor, so one jar links on all three. (get(String) does not work — compiled against Spring 6, javac still emits the (Object) descriptor.)
• mvc-annotation-commons RequestUtil — same removal, fixed with getValuesAsList(String).
• mvc-annotation-commons — ServerHttpResponse#getRawStatusCode() was also removed in Spring 7.

We also added proper Spring-generation witnesses to both WebFlux plugins. The only guard was WitnessMethod(Mono, contextWrite), which bounds Reactor, not Spring — which is precisely why the plugin attached to Spring 7 and then failed on every request instead of cleanly not attaching.

Separately, while investigating we found apm-toolkit-webflux has been broken since Spring Boot 3.0 (Nov 2022): Reactor removed Signal#getContext() in 3.5.0, so three of the five continueTracing overloads throw NoSuchMethodError. That is application code, so nothing swallows it. It is fixed in the same PR by splitting the toolkit into apm-toolkit-webflux-5.x and apm-toolkit-webflux-6.x. If you use the WebFlux tracing assistant APIs, you will want -6.x.

Version support

spring-webflux-6.x now covers Spring Framework 6 and 7, so no separate webflux-7.x plugin is needed. Supported ranges extended to WebFlux/WebClient/Spring MVC/RestTemplate 7.x and Spring Cloud Gateway 5.0.x. No existing version loses support.

Verified

New plugin test scenarios drive a full round-trip and assert the cross-process ref, since that is the only thing that proves the sw8 header is read back correctly. Verified on Spring Boot 3.5.16 and 4.0.8, and Spring Cloud Gateway 5.0.3 on Boot 4. Also negative-tested: reverting the one-line fix reproduces your exact NoSuchMethodError and fails the scenario, so it is a real regression guard.

In the meantime

Until 9.8.0 ships, you can build the agent from the PR branch (support-spring-framework-7) — ./mvnw clean package -Dmaven.test.skip=true — and use skywalking-agent/, remembering to copy optional-plugins/apm-spring-cloud-gateway-4.x-plugin-*.jar into plugins/ as you do today.