[Test] Add Spring Cloud Gateway 4.3.3 and 5.0.0 to gateway scenario

[Siman-hub]

Summary

This PR adds Spring Cloud Gateway 4.3.3 and 5.0.0 to the gateway-4.x-scenario test matrix.

Compatibility Analysis

I verified source-level compatibility of NettyRoutingFilter in Gateway 4.3.3 and 5.0.0 against the existing v412x plugin.

• Structure change: Gateway introduces getHttpClientMono, which is invoked by the main filter flow.
• Safety check: In both versions, the implementation remains eager:

// org.springframework.cloud.gateway.filter.NettyRoutingFilter (v4.3.3)
protected Mono<HttpClient> getHttpClientMono(Route route, ServerWebExchange exchange) {
    return Mono.just(getHttpClient(route, exchange));
}

• Conclusion: Since Mono.just is evaluated immediately on the calling thread, getHttpClient(...) (which SkyWalking instruments) is still executed synchronously during request handling. Execution order and context propagation remain unchanged, so the existing plugin continues to work as intended for both 4.3.3 and 5.0.0.

Verification

• Validated source compatibility (NettyRoutingFilter structure).
• Validated binary compatibility (Plugin compiles against 4.3.3 and 5.0.0).
• Runtime verification delegated to CI (Local Windows environment limitations prevented full Docker scenario execution).

[Siman-hub]

I’ve reverted the inclusion of Gateway 5.0.x from this PR.

Reason: the current gateway-4.x-scenario is based on a Spring Boot 3.x environment, and Gateway 5.0.x seems to require a newer Spring Boot / Spring Framework baseline, which caused dependency resolution conflicts in the existing scenario.

For now I’ll keep this PR focused on Gateway 4.3.3.

I’m happy to follow up separately for Gateway 5.x — please let me know if introducing a dedicated gateway-5.x-scenario sounds like the right approach.

[wu-sheng]

I’ve reverted the inclusion of Gateway 5.0.x from this PR.

Reason: the current gateway-4.x-scenario is based on a Spring Boot 3.x environment, and Gateway 5.0.x seems to require a newer Spring Boot / Spring Framework baseline, which caused dependency resolution conflicts in the existing scenario.

For now I’ll keep this PR focused on Gateway 4.3.3.

I’m happy to follow up separately for Gateway 5.x — please let me know if introducing a dedicated gateway-5.x-scenario sounds like the right approach.

It depends whether 5.x requires a new plugin implementation. If not, you could just add a new test scenario for 5.x, copy most of codes from here, and change Spring version to newer.

[Siman-hub]

I’ve reverted the inclusion of Gateway 5.0.x from this PR.
Reason: the current gateway-4.x-scenario is based on a Spring Boot 3.x environment, and Gateway 5.0.x seems to require a newer Spring Boot / Spring Framework baseline, which caused dependency resolution conflicts in the existing scenario.
For now I’ll keep this PR focused on Gateway 4.3.3.
I’m happy to follow up separately for Gateway 5.x — please let me know if introducing a dedicated gateway-5.x-scenario sounds like the right approach.

It depends whether 5.x requires a new plugin implementation. If not, you could just add a new test scenario for 5.x, copy most of codes from here, and change Spring version to newer.

Thanks for the guidance!

I checked NettyRoutingFilter in Gateway 5.x and the main interception point (getHttpClient) still looks structurally similar to 4.x, so my current assumption is that the existing plugin might continue to work.

I’ll follow your suggestion and add a separate gateway-5.x-scenario (copied from 4.x with upgraded Spring/Gateway versions) to validate runtime behavior. If I hit any incompatibilities requiring plugin changes, I’ll report back.

[wu-sheng]

If this 4.x test passes, please add plugin docs and change log to indicate this new supported version.

[wu-sheng]

It seems 4.3.3 doesn't work.

[Siman-hub]

Thanks — I’m reproducing the failing gateway-4.x-scenario-jdk17 locally now to pinpoint the exact runtime failure (startup vs assertion).
I’ve completed a full build successfully and am running the scenario to capture the concrete error.
I’ll report back once I have the root cause so we can decide whether this needs scenario dependency updates or plugin adjustments.

[Siman-hub]

I've updated the branch. I managed to get the gateway-4.3.x-scenario passing locally. The fixes in this push include:

1. Infrastructure: Switched the base Docker image to eclipse-temurin:17-jdk-jammy (the previous image lacked bash, which was causing the runner script to fail silently).
2. Test Data: Updated expectedData.yaml to correctly match the split-segment trace structure of the reactive Gateway 4.x and filtered out health check noise. Verified locally with exit code 0.

[wu-sheng]

I've updated the branch. I managed to get the gateway-4.3.x-scenario passing locally. The fixes in this push include:

1. Infrastructure: Switched the base Docker image to eclipse-temurin:17-jdk-jammy (the previous image lacked bash, which was causing the runner script to fail silently).

I have a little concern about hard coded to this image only when this simple one test scenario.
Did not other case require bash?

[Siman-hub]

I've updated the branch. I managed to get the gateway-4.3.x-scenario passing locally. The fixes in this push include:

1. Infrastructure: Switched the base Docker image to eclipse-temurin:17-jdk-jammy (the previous image lacked bash, which was causing the runner script to fail silently).

I have a little concern about hard coded to this image only when this simple one test scenario. Did not other case require bash?
The main difference here is the JDK 17 requirement for Spring Cloud Gateway 4.3.x (via Spring Boot 3), while most other scenarios still run on JDK 8/11.
It looks like the default JDK 17 images are much more stripped down and often don’t include bash, which causes scenario.sh to fail. I pinned eclipse-temurin:17-jdk-jammy to ensure a standard Ubuntu user space with the tools the runner expects.
If you’d prefer a different approach like installing bash explicitly or aligning this with other scenario, I’m happy to adjust.

[wu-sheng]

Yes. please go for install bash for all JDK17 cases.
And the CI seems failing, please recheck.

[Siman-hub]

Hi @wu-sheng, thanks for the guidance.

I’ve updated the agent-test-jvm image to install bash during build (via docker-maven-plugin) and removed the gateway-specific JDK override from run.sh. Gateway 4.3.x now relies on the existing JDK17 CI workflows to select the runtime image, and I’ve verified the scenario passes locally with --base_image_java eclipse-temurin:17-jdk.

Could you please take another look when convenient? Thanks!