spring-cloud
Avoid or document the pitfalls of the bootstrap context
From what I've seen, the separate bootstrap context and its consequences continue to surprise users. The latest example is with disabling auto-configuration of Reactor's debug agent. I think it would be an improvement if users didn't have to know so much about the bootstrap context and its presence didn't require some configuration to move from application.yaml to bootstrap.yaml.
I can't recall the history of the context, but I wonder if it's still needed now that we have the environment post-processor extension point. If it is still needed, I wonder if it could be made a bit more "closed world" so that extensions that are really aimed at the main application context are not picked up by the bootstrap context. Failing that, documenting the problem and the need to move some configuration properties would help I think.
I think we'll have an opportunity in Ilford to do some major refactoring.
As far as I understand we noticed two things due to the bootstrap context:
- The log metrics do not work properly (known issue)
- It seems we receive two
ApplicationReadyEvents here
Another item from https://github.com/spring-cloud/spring-cloud-vault/issues/398:
When /actuator/refresh is called the BootstrapApplicationListener is rerun. It may be nice for bootstrap configurations to respond to an event rather than being rerun blindly.
Also see #380