This follows up on https://github.com/spring-projects/spring-boot/issues/41839, and in particular:
I've put a work-around in for M2, but I think we might need a better long-term solution. In hindsight, we should probably not have used DynamicPropertyRegistry but instead have our own interface.
Comment From: snicoll
A DynamicPropertyRegistry bean does not provide any built-in resolution mechanism and the @Bean method that's invoked to mutate the Environment may easily be invoked after the related component has been created. This may cause issues that are very hard to track. As a framework mechanism without an intuitive (or out-of-the-box) mechanism to deal with this issue, one should wonder if it should be exposed at all until it does.
We need to have a discussion with the framework team about this.
Comment From: wilkinsona
I've prototyped some changes to Boot that make use of Framework's new DynamicPropertyRegistar. The prototype currently needs to use reflection as Framework's DynamicPropertyRegistrarBeanInitializer is package-private. I've opened https://github.com/spring-projects/spring-framework/issues/33593 to see if Framework can provide use with an SPI for bootstrapping the DynamicPropertyRegistrar support outside of the test context framework.
Comment From: wilkinsona
The bean initializer's now public so the prototype no longer needs to use reflection. The prototype's been updated to this effect. I think this is pretty close now but I'd like to have another round of discussion with the team, particularly around how we bring the deprecation to people's attention.
Comment From: wilkinsona
We'd like a failure by default rather than just a warning. We'll then provide a property to change this behavior with supported values being something like fail, warn, or ignore. fail would be the default.