Skip to content

Improve setEnvironmentPrefix(...) reference documentation #45370

Closed
@GrahamHannington

Description

@GrahamHannington

With no environment prefix set, the following environment variables work:

SPRING_CONFIG_ADDITIONALLOCATION=file:../shared/
SPRING_PROFILES_ACTIVE=server-public

That is, my Spring Boot app loads the corresponding profile-specific file ../shared/nexus-server-public.yaml, and the app uses the property values set in that file, such as the server.port value.

Note:

  • The Java command line for the app sets --spring.config.name=nexus.
  • The app uses Spring Boot 3.1.12 (yes, old).

If I set the environment prefix "nco" (here's the corresponding snippet from the app main() function):

SpringApplication application = new SpringApplication(DataStreamerApplication.class);
application.setEnvironmentPrefix("nco");
context = application.run(args);

then, as expected, those (unprefixed) environment variables no longer "work".

Interestingly, though, the app log reports that profile as being active, but the log also shows that the app does not use the server port value set by that profile-specific file.

The problem: This tells me that, with an environment prefix set, my app is using SPRING_PROFILES_ACTIVE, but not SPRING_CONFIG_ADDITIONALLOCATION.

Sure enough, if I add the prefix NCO_ to the variable name SPRING_CONFIG_ADDITIONALLOCATION, then it works: the app uses the server.port set in the profile-specific file in that additional location.

However, if I also add the prefix NCO_ to SPRING_PROFILES_ACTIVE, then the application log reports "No active profile set".

That is, my app recognizes NCO_SPRING_CONFIG_ADDITIONALLOCATION as a configuration property, but not NCO_SPRING_PROFILES_ACTIVE.

If this is a bug in Spring Boot, then: please fix it.

If this is working as designed, then: please enhance the docs to describe, if an environment prefix is set, which configuration properties should be specfied with that prefix, and which (e.g. SPRING_PROFILES_ACTIVE) should not.

Another possibility is that my app is causing this behavior. I've already considered that, but I can't see any reason for it, hence this issue. I acknowledge that I haven't taken the time to create a minimal app using the latest release of Spring Boot and attempt to reproduce this behavior. If Spring Boot developers respond to this issue that it's not a bug and it's not working as designed, then that will be useful to me: with apologies, I'll slink away and attempt again to figure out how the app is causing this behavior.

In any case, I suggest that the Spring Boot docs about the environment prefix could be enhanced.

In the related GitHub issue, "Add prefix support for environment variables", #3450, @philwebb wrote:

a prefix ... Which would then bind MYAPP_SERVER_PORT rather than SERVER_PORT

That concise design intent seems clear to me.

However, from the Spring Boot docs heading "Configuring System Environment Properties":

if you set the prefix to input, a property such as remote.timeout will also be resolved as input.remote.timeout in the system environment.

While I acknowledge that you "can't fix stupid" 🙂, and so this might just be my problem: those docs confuse me. Are those docs even describing the same feature as GitHub issue #3450? If so, the docs seem to me to be describing the feature "backwards". My understanding is that, if you set the prefix to input, then the environment variable INPUT_REMOTE_TIMEOUT will be resolved as the property remote.timeout. What does "also" mean in the phrase "will also be resolved as", and how does that relate to the phrase "rather than" in issue #3450?

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions