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 https://github.com/spring-projects/spring-boot/issues/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
Comment From: 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.
Comment From: 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.
Comment From: philwebb
45741 might also be related to this area.
Comment From: wilkinsona
I've opened https://github.com/spring-projects/spring-boot/issues/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.
Comment From: 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?
Comment From: 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 https://github.com/spring-projects/spring-boot/issues/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?