Rename management.context-path to more accurately reflect its purpose

[wilkinsona]

management.context-path and servlet.context-path do quite different things, but their names suggest that they have a similar purpose. We should consider renaming management.context-path to avoid confusion. In #10200, @mbhave suggested endpoints.base-path which I like. We could also consider management.endpoints.web.base-path (inspired by the existing management.endpoints.jmx.domain property).

[snicoll]

I don't like endpoints.base-path. The refactoring of 2.0 aims at keeping endpoints.* for only endpoints specific concerns (with the exception of the "default" endpoint).

management.endpoints.* looks like the right place for this.

[wilkinsona]

I'm wondering if we should expand the scope of this a little and use it as a general issue for refining the configuration of the management server. There are lots of general management properties that are actually specific to the management server:

• management.add-application-context-header
• management.address
• management.context-path
• management.port
• management.ssl.*

I think they'd all benefit from moving to management.server.*.

Thinking some more, we may also want to keep management.context-path and also introduce a property for the base endpoint path. management.context-path would then do the same thing as server.context-path but only when management.port is set. The endpoint base path would then be relative to server.context-path when management.port is not set (as it is today), and management.server.context-path when management.port is different.

[mbhave]

I like the idea of keeping management.context-path and introducing a new one for the endpoints base path because that would accurately describe how they both work.

[wilkinsona]

Looks like we're in favour of making this change. Scheduling for M6.