It could be illogical this issue, but should be expanded the explanation about, what is the purpose of getEnvironment().getActiveProfiles().
Yes the method's name is explicitly is clear by itself and the javadoc is available, but the practice over the theory is not the same. It because getEnvironment().getActiveProfiles() shows or consider profiles that really were not applied.
For more details, see the following SO post
Thanks for your understanding
Comment From: snicoll
The Environment is not frozen once the context has been refreshed. You are misusing the API by mutating the spring.profiles.active property after the. context has refreshed. Essentially, you let the container start with whatever profile is there at that point and, once it has fully started, you set a different value for the property.
There are a lot of other cases where something like this happens. For instance you could have a bean that is guarded by a condition on property. If you set the property to a different value after the context has refreshed, the bean will have been created anyway and your environment won't reflect the state in which the condition was evaluated.
I am going to close this now as I don't think we should be upgrading our Javadoc for an API misuse.
Comment From: manueljordan
for an API misuse
Even with that, I think would be nice if a note or advice would be added in the current documentation. Consider the case if a kind of warning would be printed in the logs when the app starts and if this scenario is detected - therefore the developer is awared to fix that