SpringApplication.setEnvironmentPrefix is ignored when reading MANAGEMENT_SERVER_PORT

[emouty]

In spring boot 3.4.5 I could setup my management server port as an env var with a prefix since 3.5.0 this is no longer the case. This might be due to changes from #45549

I could have

@SpringBootApplication
public class SpringBootIssuesApplication {

    public static void main(String[] args) {
        SpringApplicationBuilder myApp = new SpringApplicationBuilder(SpringBootIssuesApplication.class);
        myApp.environmentPrefix("myapp");
        myApp.run(args);
    }

}

and launching my app with env var : MYAPP_MANAGEMENT_SERVER_PORT=9090 would start management server on 9090. since 3.5.0 I need to put MANAGEMENT_SERVER_PORT=9090 to have the same behavior

[wilkinsona]

Thanks for the report. This is a regression caused, at least in part, by a performance optimisation that means that the prefix isn't considered. One option is to disable the optimization when an environment prefix has been configured but I'd like to discuss this with @philwebb as there may be a better approach. A secondary problem appears to be that the prefix isn't transferred to the child context's environment. I have yet to identify the cause.

[wilkinsona]

A secondary problem appears to be that the prefix isn't transferred to the child context's environment. I have yet to identify the cause.

Rather than the prefix no longer being transferred, I believe the cause is the ManagementServerProperties now being bound in the child context due to this change. A possible fix here is to rely on the properties in the parent context where they should already exist.

[philwebb]

#45741 might also be related to this area.

[wilkinsona]

I've opened #45858 as 3.4.x also suffers from the second part of the problem. It's gone unnoticed as nothing binds @EnableConfigurationProperties(ManagementServerProperties.class) in the child management context in 3.4.x. If something does, it binds those properties ignoring the environment prefix.

[philwebb]

I think the fix I pushed for #45741 may also solve this one. @wilkinsona If you have a sample or test could you please try it again?

[wilkinsona]

I'm struggling to reproduce it now, even with 3.5.0. Either I was/am doing something daft, or there's a subtle ordering aspect to the problem which makes me wonder if the cache is involved too somehow?

I can still reproduce a failure where the property can't be bound in the child context which results in an NPE:

Caused by: java.lang.NullPointerException: Cannot invoke "java.lang.Integer.intValue()" because the return value of "org.springframework.boot.actuate.autoconfigure.web.server.ManagementServerProperties.getPort()" is null
	at org.springframework.boot.actuate.autoconfigure.web.server.ManagementWebServerFactoryCustomizer.customize(ManagementWebServerFactoryCustomizer.java:112) ~[spring-boot-actuator-autoconfigure-3.5.0.jar:3.5.0]
	at org.springframework.boot.actuate.autoconfigure.web.servlet.ServletManagementChildContextConfiguration$ServletManagementWebServerFactoryCustomizer.customize(ServletManagementChildContextConfiguration.java:127) ~[spring-boot-actuator-autoconfigure-3.5.0.jar:3.5.0]
	at org.springframework.boot.actuate.autoconfigure.web.servlet.ServletManagementChildContextConfiguration$ServletManagementWebServerFactoryCustomizer.customize(ServletManagementChildContextConfiguration.java:117) ~[spring-boot-actuator-autoconfigure-3.5.0.jar:3.5.0]
	at org.springframework.boot.actuate.autoconfigure.web.server.ManagementWebServerFactoryCustomizer.customize(ManagementWebServerFactoryCustomizer.java:88) ~[spring-boot-actuator-autoconfigure-3.5.0.jar:3.5.0]
	at org.springframework.boot.actuate.autoconfigure.web.server.ManagementWebServerFactoryCustomizer.customize(ManagementWebServerFactoryCustomizer.java:42) ~[spring-boot-actuator-autoconfigure-3.5.0.jar:3.5.0]
	at org.springframework.boot.web.server.WebServerFactoryCustomizerBeanPostProcessor.lambda$postProcessBeforeInitialization$0(WebServerFactoryCustomizerBeanPostProcessor.java:71) ~[spring-boot-3.5.0.jar:3.5.0]
	at org.springframework.boot.util.LambdaSafe$Callbacks.lambda$invoke$0(LambdaSafe.java:287) ~[spring-boot-3.5.0.jar:3.5.0]
	at org.springframework.boot.util.LambdaSafe$LambdaSafeCallback.invoke(LambdaSafe.java:159) ~[spring-boot-3.5.0.jar:3.5.0]
	at org.springframework.boot.util.LambdaSafe$Callbacks.lambda$invoke$1(LambdaSafe.java:286) ~[spring-boot-3.5.0.jar:3.5.0]
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) ~[na:na]
	at java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1116) ~[na:na]
	at org.springframework.boot.util.LambdaSafe$Callbacks.invoke(LambdaSafe.java:286) ~[spring-boot-3.5.0.jar:3.5.0]
	at org.springframework.boot.web.server.WebServerFactoryCustomizerBeanPostProcessor.postProcessBeforeInitialization(WebServerFactoryCustomizerBeanPostProcessor.java:71) ~[spring-boot-3.5.0.jar:3.5.0]
	at org.springframework.boot.web.server.WebServerFactoryCustomizerBeanPostProcessor.postProcessBeforeInitialization(WebServerFactoryCustomizerBeanPostProcessor.java:57) ~[spring-boot-3.5.0.jar:3.5.0]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:429) ~[spring-beans-6.2.7.jar:6.2.7]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1818) ~[spring-beans-6.2.7.jar:6.2.7]
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:607) ~[spring-beans-6.2.7.jar:6.2.7]
	... 25 common frames omitted

That's what #45858 is tracking.

@emouty, given "ignored" in the issue's title, I assume that this isn't the behavior that you're seeing. Can you please share a minimal example that ignores MYAPP_MANAGEMENT_SERVER_PORT when the environment prefix is set to myapp?

[emouty]

you will an example on this repo https://github.com/emouty/spring-boot-issues