Spring boot 2.4.x
As was done in this issue, where the configuration of the management context-path for Tomcat and Netty servers was unified under the property management.server.base-path
, does it make sense to do the same for the other properties?
For example:
With server.servlet.context-path
and spring.webflux.base-path
or server.tomcat.connection-timeout
and server.netty.connection-timeout
among others..
Comment From: philwebb
We've discussed the connection timeout properties in the past (see #18473) and decided it was best to keep them separate.
I'm personally not too keen on unifying server.servlet.context-path
and spring.webflux.base-path
since they are well defined terms already. The Servlet property is especially nice at the moment because it maps well to javax.servlet.ServletContext.getContextPath()
. If we rename it we break that link and we don't get a huge benefit unless users are switching between Servlet and WebFlux apps often.
Flagging to see what others in the team think.
Comment From: snicoll
Same. Those separations are also quite important as the semantics may be subtly different and trying to have a single property leads to problematic descriptions.
Comment From: bclozel
Same. The context path is strongly tied to the Servlet spec, whereas the WebFlux base path defines a different concept with different behavior. I don't think merging those is wise.
Comment From: ferblaca
OK! but for the management context-path it was unified under 'management.server.base-path'. Do you think the same for the connection-timeout properties?
Comment From: philwebb
I think unifying the management properties makes sense because users are less likely to interact with the Servlet APIs for those endpoints. The fact we're using Servlet or WebFlux is more of an implementation detail that's hopefully abstracted away.
Do you think the same for the connection-timeout properties
We've discussed the connection timeout properties in the past (see #18473) and decided it was best to keep them separate.
Comment From: philwebb
The consensus seems to be that it's best to keep the properties as they are (at least for now). Thanks anyway for the suggestion.