Description
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 thanSERVER_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 asremote.timeout
will also be resolved asinput.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?