We are using an ApplicationContext hierarchy in our Spring Boot application. Each child application has their own webserver using a unique port, that is configured through a custom child specific properties file. This works fine in spring boot 2.5. However, after upgrading to 2.6(.2), the single parent context contains already a ServerProperties instance, causing all child component to reuse that one instead of creating their own, breaking our configuration.
After some digging, the problem seems to be a change in WebSessionIdResolverAutoConfiguration. Since 2.6, that one requires ServerProperties, causing it to be added to the root context.
As a workaround, we have explicitly removed the WebSessionIdResolverAutoConfiguration from our root context (using EnableAutoConfiguration(exclude={WebSessionIdResolverAutoConfiguration.class})).
I see a similar issue was raised and fixed when migrating from 2.2 to 2.3 (https://github.com/spring-projects/spring-boot/issues/21789).
Our current way of providing different servers per child component relies on the assumption that the parent context does not contain an instance of ServerProperties. This seems to be a brittle assumption. Is there a better (more stable) approach to achieve what we are trying to do ?
Comment From: wilkinsona
Thanks for the report, @janssk1. It looks as if we could apply a fix that's similar to the fix for #21789 but I'm wondering why WebSessionIdResolverAutoConfiguration isn't @ConditionalOnWebApplication. I'm also curious to know if that would solve the problem for your context hierarchy. To that end, can you please provide a complete yet minimal sample project that reproduces the problem you're facing?
Comment From: janssk1
I have updated the example from the previous ticket: https://github.com/janssk1/spring-context-hierarchy/commit/d4d8cff71d83f7e2d13e71b62cd502e360f6c8dd
As soon as reactor-core is in the classpath (in our case, it was on the classpath for an unrelated reason), the WebSessionIdResolverAutoConfiguration kicks in and instantiates ServerProperties
Comment From: wilkinsona
Thank you. As I'd hoped, marking WebSessionIdResolverAutoConfiguration as @ConditionalOnWebApplication(type = Type.REACTIVE) allows your application to start using ports 8081 and 8082. It also continues to work after updating the sample to be a reactive web application. As part of applying that fix, we should also review other places where @EnableConfigurationProperties(ServerProperties.class) is used and ensure that they're only triggered in a web application.
Comment From: wilkinsona
WebSessionIdResolverAutoConfiguration seems to be the only place that's affected. All other uses of @EnableConfigurationProperties(ServerProperties.class) are protected with a web application condition.