Spring-cloud-config: Support applications and profiles with dashes in its names in properties, json & yml endpoints.

[ivancorrales]

At my organization ( @serenity-devstack ), we make use of the spring configuration server.
Some of our applications contain dashes as part of its name and unfortunately we got problems when making use of the below services in the class EnvironmentController (module spring-cloud-config-server),

• GET /{name}-{profiles}.properties
• GET /{label}/{name}-{profiles}.properties
• GET /{name}-{profiles}.json
• GET /{label}/{name}-{profiles}.json
• GET /{name}-{profiles}.yml
• GET /{label}/{name}-{profiles}.yml or /{label}/{name}-{profiles}.yaml

These services don't work as we expected due to the method validateNameAndProfiles(name, profiles) throw an Error.

Are you planning to support application and profiles which contain dashes as part of their names? If so, could you provide us with some work around to take in the meanwhile?

Would you consider creating new endpoints in order to support applications with dashes?

Thanks in advance
Cheers

[spencergibb]

A workaround is to create a controller with paths in a form you like that doesn't have a dash in it and wire in an EnvironmentController and delegate to it.

[ivancorrales]

Thanks for that, but unfortunately If we do that we still have the same problem since the methods in class EnvironmentController invoke validateNameAndProfiles..

Since we need to skip the above validation, a possible solution we found it would be to make some refactor in the EnvironmentController class and implement a strategy pattern that allows us to customize the validation to apply.

[dsyer]

Would you consider creating new endpoints in order to support applications with dashes?

No, probably not. If you want to contribute a fix, I would say that you have to use the existing endpoints, and choose whether to accept application names or profiles with embedded dashes. I expect whatever you propose will involve parsing the HttpServletRequest (which is ugly and I wish it were not necessary, see https://jira.spring.io/browse/SPR-14193).

[otrosien]

Please consider adding a new endpoint to resolve the ambiguity here. Not being able to have dashes in application names is a big drawback. (is it at least stated in the documentation somewhere?)

[dsyer]

You can have dashes in application names. It just doesn't necessarily work with the .properties and .yml endpoints.

[jorgenota]

Suggestion:

1. Keep the same endpoints but allow dashes in application names with all the endpoints (included the .properties and .yml endpoints). The profile names with dashes would keep failing with some endpoints but at least app names would work.
2. Document the drawback, as @otrosien suggests.

If dashes are needed for profile names too, maybe it could be addressed at a different issue asking for new endpoints...

[dsyer]

@jorgenota sounds reasonable. We'd want a PR in the next couple of days if it is to make it into 1.1.0.

[jmandawg]

So will @ivancorrales patch make it to 1.1.0.RELEASE?

We would really like to keep the convention of artifactId = spring.application.name but artifactId standard is to use dashes.

[spencergibb]

It did not make it.

[ivancorrales]

Do you plan to add it to the next release?