following up with GSIP-226 (GeoServer 3) we have a set of pull requests migrating the GeoServer ecosystem to Spring 7, in order to get longer term support from that critical library (Spring 6 is going to be EOL middle of the year, if they don’t change their plans).
Coming along with Spring 7 is the upgrade from Jackson 2 to Jackson 3, as Spring 7 deprecated Jackson 2 support.
The spring-security upgrade was uneventul, but only because the security subsystem already has a robust set of deprecation suppressions… when switching to Spring 8 some significant parts will have to be rewritten. Regardless, tests are passing in all supported land. The unsupported OIDC module has two failures in the KeycloackIntegrationTest, but I cannot quickly figure out what’s going on, someone with more experience with OIDC would probably better.
To go along with the rest we’re expecting some changes to the printing module, an upgrade to the HTTP client and a Spring 7 update there as well (MapFish Print seems to be using Spring as a dependency injection framework, but I don’t see usage of MVC/Controllers). I’m not sure about what’s going there, out of a whim I changed the Spring version to 7 in the main pom, and it’s still building fine, althought I cannot vouch for actual working. The two extremes are either that it’s really that simple, or that the testing is weak and the actual issues will pop up only with actual usage.
Anyhow, how to proceed from here:
If you have any feedback, please let us know ASAP
If you can please review the PRs and/or try them out
Someone (Alessio, Cecile?) to check the OIDC test failure
Just remember to rebase your code onto main otherwise you will get compiler errors:
<compileError severity="ERROR(400)" line="31" endLine="31">
'registerModule(com.fasterxml.jackson.databind.Module)' in 'com.fasterxml.jackson.databind.ObjectMapper' cannot be applied to '(com.bedatadriven.jackson.datatype.jts.JtsModule)'
</compileError>
Also, are these new warnings (over 40 of them) at startup related to the Spring upgrade?
...
10 Feb 16:52:03 WARN [support.PostProcessorRegistrationDelegate$BeanPostProcessorChecker] - Bean 'urlMasterPasswordProvider' of type [org.geoserver.security.password.URLMasterPasswordProvider$SecurityProvider] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected/applied to a currently created BeanPostProcessor []? Check the corresponding BeanPostProcessor declaration and its dependencies/advisors. If this bean does not have to be post-processed, declare it with ROLE_INFRASTRUCTURE.
10 Feb 16:52:04 WARN [support.PostProcessorRegistrationDelegate$BeanPostProcessorChecker] - Bean 'authenticationManager' of type [org.geoserver.security.GeoServerSecurityManager] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected/applied to a currently created BeanPostProcessor []? Check the corresponding BeanPostProcessor declaration and its dependencies/advisors. If this bean does not have to be post-processed, declare it with ROLE_INFRASTRUCTURE.
10 Feb 16:52:04 WARN [support.PostProcessorRegistrationDelegate$BeanPostProcessorChecker] - Bean 'configurationLock' of type [org.geoserver.GeoServerConfigurationLock] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected/applied to a currently created BeanPostProcessor []? Check the corresponding BeanPostProcessor declaration and its dependencies/advisors. If this bean does not have to be post-processed, declare it with ROLE_INFRASTRUCTURE.
10 Feb 16:52:06 WARN [support.PostProcessorRegistrationDelegate$BeanPostProcessorChecker] - Bean 'customCRSAuthorityLoader' of type [org.vfny.geoserver.crs.CustomCRSAuthorityLoader] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected/applied to a currently created BeanPostProcessor []? Check the corresponding BeanPostProcessor declaration and its dependencies/advisors. If this bean does not have to be post-processed, declare it with ROLE_INFRASTRUCTURE.
Hi Peter,
yes, they are there since the Spring 6 upgrade.
I’ve followed up with a couple of ideas in this comment and discussed quickly with Jody on chat,
he did not seem satisfied with either but hasn’t come back with a third approach yet.
We were able to catch up and I am going to round up Andrea’s solution (adjusting logging levels).
It seems much easier to maintain then marking beans as “infrastructure”.