Wildcard for '{application}' not working for plain text serving

[pjoshi751]

Hi,

After installing the config server I tried fetching a plain text file as:

$ wget http://config-server/*/mz/develop/filename.xml

I see the following error in config server logs:

herServlet] in context with path [] threw exception [Request processing failed; nested exception is org.springframework.cloud.config.se
rver.environment.FailedToConstructEnvironmentException: Could not construct context for config=* profile=mz label= includeOrigin=false;
 nested exception is java.lang.IllegalStateException: Config name '*' cannot contain wildcards] with root cause

As per documentation the above should work. When I give some random text instead of '*', it works:

$ wget http://config-server/xyz/mz/develop/filename.xml

Not sure why it is not allowing wildcards.

[hyness]

I see in the Spring Cloud Config Server documentation that you can configure a remote Git repository with wildcards. From reading the stacktrace you provided, it seems you have configured a native repository. Is that correct? The error message is coming directly from Cloud Config, not this image. It very plainly states that a config name cannot contain wildcards. I cannot find anything in the documentation that states you can query Cloud Config with wildcards. Can you point me to the documentation to which you are referring?

[pjoshi751]

Thanks for your reply. Here is the documentation. https://cloud.spring.io/spring-cloud-config/reference/html/#_serving_plain_text (see the box and example in there)

My repository is on Github, not local. I am pretty sure wildcards work 'cause we have our own spring cloud config server docker, and such urls do work. However, I didn't want to maintain and change that docker so opted for the one you've created.

[hyness]

Ok, I think I see what you are referring to https://docs.spring.io/spring-cloud-config/docs/2.2.4.RELEASE/reference/html/#_serving_plain_text

Instead of using the Environment abstraction (or one of the alternative representations of it in YAML or properties format), your applications might need generic plain-text configuration files that are tailored to their environment. The Config Server provides these through an additional endpoint at /{application}/{profile}/{label}/{path}, where application, profile, and label have the same meaning as the regular environment endpoint, but path is a path to a file name (such as log.xml). The source files for this endpoint are located in the same way as for the environment endpoints. The same search path is used for properties and YAML files. However, instead of aggregating all matching resources, only the first one to match is returned.

More specifically, I think you are referring to this

As with the source files for environment configuration, the profile is used to resolve the file name. So, if you want a profile-specific file, //development//logback.xml can be resolved by a file called logback-development.xml (in preference to logback.xml).

I personally have never used the plain text feature, but how that documentation reads to me is that if you want the filename.xml for the development profile, you can call it with any values, and the first file it finds with that profile will be returned. This seems to match with your findings as well. I think this is just how cloud config server works. If you point me to an example working the way you describe or provide a sample project in java/kotlin, I can investigate this further.

[hyness]

If you can provide a sample project demonstrating the issue, I'll reopen this issue