The behaviour is as follows when starting with server.port=-1:
- Jetty: app starts and stays running, but is not listening for HTTP connections
- Netty: app fails to start as -1 is an illegal port number
- Tomcat: app starts and stays running, but is not listening for HTTP connections
- Undertow: app starts and then stops
Further to the above, the way that autoStart is implemented at the moment is a little odd. When a web server is created with autoStart set to false, calling start() on that server will then have no effect and there's no way to set autoStart back to true so that the web server can be started. In other words, it's not really disabling automatic start, but disabling start altogether.
Comment From: wilkinsona
We'd like to align Netty and Undertow with Jetty and Tomcat. We'll decide if the fix should go in 2.1.x or if it should wait till 2.2 depending on how risky it seems.
Comment From: sandeshm22
https://github.com/spring-projects/spring-boot/pull/20005
Comment From: wilkinsona
Something that I don't think we've considered before is how to handle any additional connectors that may have been registered through user-provided customizers. For example, if server.port is set to -1 but a TomcatWebServerFactory has additional connectors configured that use other ports, should those connectors still listen?
The documentation says the following:
To switch off the HTTP endpoints completely but still create a org.springframework.web.context.WebApplicationContext, use
server.port=-1(doing so is sometimes useful for testing).
To me, this suggests that setting server.port to -1 should mean that the web server doesn't listen on any ports. On the other hand, setting server.port to any other value has no effect on any additional connectors so why should -1 behave any differently?
I wonder if we should replace the special treatment of server.port=-1 with a new property (maybe server.listen) that can be set to false to disable listening on any port.