Error: HTTP service failed to start due to NoSuchMethodError in WebAppContext during locator startup in Spring Boot 3.5

Products

VMware Tanzu Data VMware Tanzu Data Intelligence VMware Tanzu Data Suite VMware Tanzu Data Suite VMware Tanzu Gemfire

Issue/Introduction

When launching a locator or node, the integrated Pulse monitoring console and GemFire Management Console (GMC) fail to initialize properly. This behavior occurs after upgrading application modules to o Spring 6.2 and Spring Boot 3.5 with GemFire 10.1.2 frameworks. The system context completely cancels the application refresh attempt during early initialization phases.

Symptoms:

The runtime logs output a context initialization exception tied directly to the asyncTaskExecutor configuration.
Manually overriding embedded container dependencies to higher major baselines causes immediate startup crashes.
The following critical log block is observed:

org.apache.geode.management.ManagementException: HTTP service failed to start
Caused by: java.lang.NoSuchMethodError: 'org.eclipse.jetty.webapp.ClasspathPattern org.eclipse.jetty.webapp.WebAppContext.getSystemClasspathPattern()'

Environment

Spring Boot 3.5.x
Spring Framework 6.2.x
GemFire 10.1.2 HTTP Service Module
Jetty 11.0.9+ / Jetty 12.x dependencies

Cause

The embedded management server tools in older platform binaries build explicitly against Jetty 9 structural boundaries. When forced onto a Spring Boot 3.5 infrastructure, severe classpath regressions occur due to two breaking changes introduced after Spring Boot 3.0:

Root cause is as follows:

Two breaking changes introduced after Spring Boot 3.0 conflict with GemFire's Jetty 9-based HTTP Service:
- Servlet API Namespace Migration (since Spring Boot 3.0)
  - Before : javax.servlet.*
  - After : jakarta.servlet.*
  - Impact : These are treated as entirely different types at the JVM level. No coexistence is possible within the same JVM instance.
- Embedded Jetty Package Restructuring (since Spring Boot 3.2)
  - Before (Jetty 9/11) : org.eclipse.jetty.servlet.* , org.eclipse.jetty.webapp.*
  - After (Jetty 12) : org.eclipse.jetty.ee10.servlet.*, org.eclipse.jetty.ee10.webapp.*
- The following classes referenced by GemFire InternalHttpServicehave been removed from Jetty 12:
  - org.eclipse.jetty.server.handler.HandlerCollection
  - org.eclipse.jetty.server.handler.ContextHandler$AliasCheck
  - org.eclipse.jetty.webapp.WebAppContext

WHY IT WORKED ON SPRING BOOT 3.1

Spring Boot 3.1 defaults to Jetty 11.x. Since Jetty 9 and Jetty 11 share identical package paths (org.eclipse.jetty.servlet.*, org.eclipse.jetty.webapp.*), forcing Jetty 9 via ext['jetty.version'] = '9.4.x' allowed both Spring Boot 3.1 and GemFire HTTP Service to resolve the same classes successfully. This was coincidental compatibility due to shared package naming, not officially supported behavior.

WHY IT FAILS ON SPRING BOOT 3.5

Starting with Spring Boot 3.2, the embedded server was fully migrated to Jetty 12's ee10 package structure, which is entirely different from Jetty 9's package paths. This results in the following runtime error:

ServiceConfigurationError:
    org.apache.geode.internal.cache.CacheService: org.apache.geode.internal.cache.http.service.InternalHttpService Unable to get public no-arg constructor  Caused by: ClassNotFoundException: org.eclipse.jetty.server.handler.ContextHandler$AliasCheck

Code-level workarounds — including subclassing JettyServletWebServerFactory or directly implementing ServletWebServerFactory — are all ruled out due to the javax vs jakarta Servlet API type incompatibility at the JVM level.

Resolution

This issue is under active engineering review. A code-level correction within the underlying connector framework is required to ensure compatibility with modern dependency baselines.

Targeted to be fixed in an upcoming release of the spring-boot-3.5-gemfire-10.1 library adapter.

To resolve this issue immediately, implement the following operational procedures:

Retain the parent deployment configuration on Spring Boot 3.1.x using standard Jetty 9 framework overrides if local dashboard functionality is mandatory.
Subscribe to this article to receive real-time notifications when the formal patch becomes available. See How to subscribe to Broadcom Knowledge Base Articles.