Find a better way to detect when to start embedded servers

[philwebb]

See https://jira.spring.io/browse/SPR-16760 and rabbitmq/hop#122 for some of the issues we currently have detecting when to start a server for Spring WebFlux.

We need to consider the spring-webflux jar to be more like spring-web and not spring-webmvc. The webflux jar alone is not a strong enough signal that an embedded server should be started.

[philwebb]

From @rstoyanchev on SPR-16760

What if the model was reversed? Make no assumptions from the presence of spring-webflux and instead look for a more explicit indication of the intent to start a WebFlux server. A webflux starter is just such an indication and hence my question. Is there no feasible way to detect what starters were declared, or is the objection purely about making such a check in the first place? Arguably in this case, it would be the very intent to differentiate between the declaration of a starter and the mere presence of a dependency.

In my opinion the starter POMs should not be a direct indication of intent. I think it's important that starters only declare dependencies, and those dependencies are indirectly responsible for auto-configuration. The problem we have with WebFlux is there is no clear indication of intent:

• spring-webflux = Client and Server components
• reactor-netty = Client and Server components
• netty = Client and Server components

SPR-16760 is about splitting spring-webflux but it seem unlikely that we could do that at this point. We could potentially split reactor-netty, but that seems extreme. We've got no chance of splitting netty.

One option we could consider is moving org.springframework.boot.web.embedded to a new jar. This would allow us to have a single dependency that is a strong indication that an embedded server should be started.

[spencergibb]

Since with tomcat and jetty you have a clear conditional to use.

[philwebb]

In Spring Framework 5.1 you'll be able to use WebClient without Netty which may solve one of the main use cases. I'm tempted to say we should do nothing until that's in place and we see if people have any issues after that change.

[sdeleuze]

I am not sure to understand how that will help solving this. Spring Framework 5.1 will indeed allow to use Jetty as an alternative to Netty, but Netty should IMO remains the default client engine for various reasons: shared infra with the default server, more mature, more efficient memory allocation since Jetty currently only allows ByteBuffer copy not efficient wrapping. Any thoughts?

[bclozel]

@sdeleuze then I'm not sure what do you have in mind - how could we solve this?

[sdeleuze]

Sorry in advance if that's a stupid proposal, but what about starting WebFlux server only when we find concrete indication of server-side code in user project. For the functional API, we could rely on something like @ConditionalOnBean(type = "org.springframework.web.reactive.function.server.RouterFunction"), and for the annotation-based model, maybe on something like @ConditionalOnBean(annotation = Controller.class) if meta-annotations are supported?

[philwebb]

Unfortunately I don't think that's an option since we need to make the decision about what ApplicationContext to create before the context is populated with bean definitions.

[rstoyanchev]

What about the original suggestion at the top to move org.springframework.boot.web.embedded to a new jar?

[philwebb]

That's certainly still an option. I guess we were hoping that using WebClient without Netty was going to become the recommended approach for client only applications.