[spring-projects/spring-boot]找到更好的方法来检测何时启动嵌入式服务器

来自 SPR-16760 上的 @rstoyanchev

如果模型反过来会怎样？不要对 spring-webflux 的存在做出任何假设，而是寻找更明确的启动 WebFlux 服务器意图的指示。 webflux 启动器就是这样一个指示，因此也是我的问题。是否没有可行的方法来检测声明了哪些首发，或者反对纯粹是为了首先进行这样的检查？可以说，在这种情况下，区分启动器的声明和依赖项的单纯存在正是意图。

在我看来，起始 POM 不应该直接表明意图。我认为初学者只声明依赖项很重要，而这些依赖项间接负责自动配置。我们遇到的问题WebFlux是没有明确的意图指示：

• spring-webflux= 客户端和服务器组件
• reactor-netty= 客户端和服务器组件
• netty= 客户端和服务器组件

SPR-16760 是关于分裂的spring-webflux，但目前我们似乎不太可能做到这一点。我们可能会分裂reactor-netty，但这似乎很极端。我们没有分手的机会了netty。

我们可以考虑的一个选择是换org.springframework.boot.web.embedded一个新的罐子。这将使我们能够拥有一个单一的依赖关系，该依赖关系强烈表明应该启动嵌入式服务器。

因为使用 tomcat 和 jetty 你有一个明确的使用条件。

在 Spring Framework 5.1 中，您将能够WebClient在没有 Netty 的情况下使用，这可能会解决主要用例之一。我很想说，在落实到位之前我们什么都不应该做，看看人们在改变后是否遇到任何问题。

我不确定这将如何帮助解决这个问题。 Spring Framework 5.1 确实允许使用 Jetty 作为 Netty 的替代品，但在我看来，Netty 应该因各种原因而保留为默认客户端引擎：与默认服务器共享基础设施、更成熟、更高效的内存分配，因为 Jetty 目前只允许ByteBuffer复制，效率不高包装。有什么想法吗？

@sdeleuze 那么我不确定你在想什么 - 我们如何解决这个问题？

如果这是一个愚蠢的建议，请提前抱歉，但是只有当我们在用户项目中找到服务器端代码的具体指示时才启动 WebFlux 服务器怎么样？对于函数式 API，我们可以依赖类似的东西@ConditionalOnBean(type = "org.springframework.web.reactive.function.server.RouterFunction")，而对于基于注释的模型，也许可以依赖诸如@ConditionalOnBean(annotation = Controller.class)是否支持元注释之类的东西？

ApplicationContext不幸的是，我认为这不是一个选择，因为我们需要在用 bean 定义填充上下文之前决定要创建什么。

顶部将 org.springframework.boot.web.embedded 移动到新 jar 的原始建议怎么样？

这当然仍然是一个选择。我想我们希望WebClient不使用 Netty 来使用将成为仅客户端应用程序的推荐方法。

我会将其移回待办事项并再考虑一下。

这建议执行其中一项操作：

1. 如果人们只spring-webflux想要.添加会带来额外的依赖，打开服务器自动配置reactor-nettyWebClientspring-boot-starter-webfluxorg.springframework.boot.web.embedded
2. 或者我们需要有两个不同的启动器：spring-boot-starter-webflux和spring-boot-starter-webclient

现在我对其中任何一个都不相信。

图书馆确实就是这样。这是两个已经存在的具体例子。 Spring Integration依赖项和文档，以及 Spring Vault依赖项和文档。请注意，有大量的 spring 项目使用 RestTemplate，因此随着时间的推移，更多此类示例将具有强大的优势。

我赞成 Brian 列表中的选项 2。但澄清一下，这还需要将功能拆分web.embedded到一个新的 jar 中吗？或者我们是否接受罗森的建议，即自动配置检测可以仅以启动器的存在为条件？

我不太热衷于单独使用启动器作为指示。我宁愿我们将初学者纯粹作为依赖项。

除了提供依赖项之外，启动器不应该用于任何其他用途，我认为改变这一点将是一个错误。至于客户端启动器，我们过去曾提出过该请求（对于 MVC），但与此问题无关，我们拒绝了它。

IMO，这个问题的底线是 netty 没有模块化（所以也不是reactor-netty）。如果情况不同，那么场景RestTemplate将会非常一致。实际上，何时WebClient支持其他 http 客户端，它将与 Spring MVC 非常一致（添加spring-web+ http 客户端 jar 与添加spring-webflux以及任何为 Jetty 提供支持的库）。

我对罗森分享的链接感到担忧。鉴于现状是通过完整的服务器实现来提供完整的服务器基础设施，我想知道是否不应重新考虑该选择。

ApplicationContext不幸的是，我认为这不是一个选择，因为我们需要在用 bean 定义填充上下文之前决定要创建什么。

观点已被采纳，但我们不能以编程方式使用相同的逻辑（例如在 中），ReactiveWebServerApplicationContext#onRefresh仅当存在一个RouterFunctionbean 或至少一个用 注释的 bean时才有条件地启动 Web 服务器@Controller吗？

这建议执行其中一项操作：

1. 如果人们只spring-webflux想要.添加会带来额外的依赖，打开服务器自动配置reactor-nettyWebClientspring-boot-starter-webfluxorg.springframework.boot.web.embedded
2. 或者我们需要有两个不同的启动器：spring-boot-starter-webflux和spring-boot-starter-webclient

现在我对其中任何一个都不相信。

我对这两种选择都很满意，因为我正在努力保持 ArcadeDB 的客户端库不依赖于 Web 服务器。使用我的库的应用程序可以自由选择是否启动服务器，但如果不需要，我的库不应强制应用程序处理对服务器的依赖关系。

上述问题https://github.com/spring-projects/spring-boot/issues/34198是我打开的，因为我认为正确的自动配置应该仅在类路径中配置和启动服务器。