Add property to transparently migrate deprecated endoint IDs

[philwebb]

Currently Spring Cloud have a number of endpoints that use a legacy name (for example hystrix.stream). They would like to give users the opportunity to migrate to the new name whilst still supporting the old one.

Ideally this would mean that endpoint references in properties can be referred to by either name, and that several mappings would be setup.

For example, hystrix.stream would be mapped to /hystrix.stream and /hystrixstream

[ryanjbaxter]

It would be nice if this could make it into the 2.1.x stream as well

[philwebb]

I don't think that's possible, it's almost certainly going to involve some fairly risky changes and it definitely feels like an enhancement rather than a bug.

[spencergibb]

I'm ok if it's 2.2.

This is the definition of hystrix endpoint

@ServletEndpoint(id = "hystrix.stream")

and

@RestControllerEndpoint(id = "hystrix.stream")

In commons the other is

@Endpoint(id = "service-registry")

[ryanjbaxter]

@philwebb can't blame me for trying ;)

@spencergibb there is also a WebFlux implementation that is using @RestControllerEndpoint

[philwebb]

I've spent the morning looking into this and it's going to be very difficult to support multiple paths for the same endpoint. We'd need to rework the Spring MVC, WebFlux and Jersey mappers and the security support. We'd also need to find a way to do that in a back compatible way.

I think we need to consider a different approach.

[spencergibb]

I think we need to consider a different approach.

Such as?

[philwebb]

One idea might be to offer a property that the user can set to transparently migrate legacy names. The experience would be that they start the app and see a warning about the use of "hystrix.stream" but also get told they can set management.endpoints.migrate-legacy-names if they want to.

If they set that property to true and restart the app then they the endpoint ID transparently changes to "hystrix.stream". Perhaps we could even set that property by default and make people opt-in to the old names if they can't make the switch easily?

[philwebb]

We spoke about this today and decided that as long as the existing IDs continue to work there's not need to support multiple path mappings. I've repurposed this issue to add migration support to allow Spring Cloud users to get ahead of the curve and pro-actively migrate if they wish.