Conversation
|
Can you submit this against the 5.0.x branch? |
a42e9e6 to
4a4529b
Compare
|
Retargeted to 5.0.x in 4a4529b. The commit cherry-picked cleanly. On 5.0.x the new test fails without the fix (AssertionError at ConfigurationPropertiesRebinderResetExclusionIntegrationTests.java:86) and passes with it; ./mvnw -pl spring-cloud-context verify gives 234 tests, 0 failures, 0 checkstyle violations. |
|
Can you look at the failing PR build? |
resetProperties consulted the spring.cloud.refresh.never-reset-nested-types exclusion only in the branch that handles a property without a setter. A property that is writable took the first branch and was overwritten with the default instance's value before the exclusion was ever considered, so a type listed in that property was still replaced during a rebind. Where the default instance leaves the field unset, that value is null, and every reader of the bean sees null until the rebind completes. Check the exclusion for the writable branch too, against both the declared property type and the class of the current value. Signed-off-by: kdelay <kdelay20@gmail.com>
4a4529b to
b362067
Compare
|
The failure is a compile error in spring-cloud-loadbalancer, which this PR does not touch (the diff is spring-cloud-context only): reactor.cache and reactor.retry not found, both from reactor-extra. I built unmodified 5.0.x (dd0d9f6) locally today: ./mvnw -pl spring-cloud-loadbalancer -am -DskipTests compile is BUILD SUCCESS, resolving reactor-extra 3.6.1, which has both packages. So the runner seems to have picked up a reactor-extra without them. I pushed b362067, an identical tree to 4a4529b, for a fresh run; it needs a workflow approval. |
3 participants
spring.cloud.refresh.never-reset-nested-types(1c3d7b0, gh-1698) only takes effect on a property with no setter. A writable one is overwritten with the default instance's value in an earlier branch ofresetProperties, before the exclusion is consulted, so it is still replaced on rebind and reads asnullwhile the default leaves the field unset. That is gh-1727.This consults the exclusion in the writable branch too, by declared type and by the runtime class. Nothing changes when the property is unset, and the reset stays best effort, as in gh-1733.
The test fails on
mainat 439ed3c (getWritable()is null after rebind) and passes with the fix../mvnw -pl spring-cloud-context verify: 234 tests, 0 failures, checkstyle and javaformat clean.Scope is that escape hatch; a primitive cannot be listed in the property.