Spring WebFlux迁移CXF SOAP服务的请求路由问题咨询

你遇到的端点无法访问问题，本质是技术栈不兼容：

• Apache CXF 默认的HTTP传输层完全基于Jakarta Servlet规范实现，你原配置里注册的CXFServlet确实是和DispatcherServlet并行运行在Tomcat Servlet容器中，Tomcat会直接把匹配/daas/activate/*、/daas/controldata/*的请求路由给CXFServlet处理，不经过Spring MVC的调度链路。
• 基于Netty的Spring WebFlux运行时完全脱离了Servlet容器，不存在Servlet上下文，ServletRegistrationBean在该环境下不会产生任何实际注册效果，所有未被WebFlux内置路由匹配的请求都会默认fallback到静态资源处理器ResourceWebHandler，这就是你访问WSDL路径被静态资源逻辑拦截的直接原因。

方案1：保留Servlet容器运行WebFlux（迁移成本最低） #

Spring WebFlux并不强制要求使用Netty作为运行容器，它本身兼容Tomcat、Jetty等Servlet容器：

• 如果你迁移到WebFlux的核心诉求是使用响应式编程模型、WebClient等响应式组件，只需要排除Spring Boot WebFlux默认的Netty依赖，引入Tomcat作为WebFlux的运行容器，此时Servlet上下文完整保留，你原有的CXF配置几乎不需要修改就能正常运行。
• 该方案下你既可以使用WebFlux的响应式能力开发新业务，也能100%兼容原有CXF SOAP服务，不需要重写任何SOAP相关逻辑，是投入产出比最高的迁移方案。

方案2：Netty运行时下的桥接适配 #

如果架构要求必须使用Netty、不能引入Servlet容器，目前Apache CXF没有发布原生适配WebFlux响应式栈的版本，你需要手动做桥接适配：

• 通过WebFlux的RouterFunction注册SOAP服务对应路径的路由，将ServerWebExchange中的请求数据转换为CXF可识别的Servlet请求格式，调用CXF的核心处理逻辑生成响应后，再写回WebFlux的响应式响应对象。
• 注意CXF本身的SOAP报文处理、服务调用逻辑都是阻塞式的，桥接时必须配置独立的阻塞线程池运行CXF逻辑，不能直接在Netty事件循环线程上执行阻塞操作，否则会严重拖垮服务吞吐量。

方案3：重构SOAP实现适配响应式栈 #

如果SOAP服务的业务逻辑不复杂、允许重构，可以直接替换Apache CXF框架：

• 基于WebFlux的注解路由或函数式路由接收SOAP请求，使用JAXB、Woodstox等XML库自行完成XML报文和Java对象的序列化/反序列化，按需实现WSDL生成、SOAP协议头处理等逻辑。该方案完全适配响应式编程模型，但需要自行处理SOAP协议的所有细节，开发和维护成本最高。

• 不要尝试在Netty环境下直接引入Servlet依赖启动CXFServlet，Netty运行时不提供Servlet容器的生命周期管理，注册的Servlet不会完成初始化，只会出现路由失效的问题。
• 桥接CXF逻辑时不要省略线程池隔离步骤，阻塞操作占用事件循环线程会导致整个服务的响应能力大幅下降。

内容的提问来源于stack exchange，提问作者Sebastian Lore