Mixed up AutoConfiguration order prevents RefreshBusEndpoint from being instantiated.

[joshiste]

The BusRefreshEndpointConfiguration matches on the ContextRefresher bean being present, but it is not guaranteed to be run after the RefreshAutoConfiguration, which adds the required bean.

This can result in a mixed up AutoConfiguration order and prevents the RefreshBusEndpoint from being instantiated when other AutoConfigurations are present (as in https://github.com/codecentric/spring-boot-admin/issues/1111).

[spencergibb]

BusRefreshConfiguration will need to be pulled out into it's own autoconfiguration to support the before. PRs welcom

[y24jds]

I have been trying to figure out why when I included spring-boot-admin-client in my dependencies, it was breaking the RefreshListener class. If I have the spring-boot-admin-client dependency, the console shows that it isn't creating RefreshListener because it doesn't think it has a refreshContext. But the odd thing is, it does have a refreshContext available for other beans like RefreshEndpointAutoConfiguration.RefreshEndpointConfiguration#refreshEndpoint

Here is how it looks when I don't have a RefreshListener BusAutoConfiguration#refreshListener: Did not match:

• @ConditionalOnBean (types: org.springframework.cloud.context.refresh.ContextRefresher; SearchStrategy: all) did not find any beans of type org.springframework.cloud.context.refresh.ContextRefresher (OnBeanCondition) Matched:
• @ConditionalOnProperty (spring.cloud.bus.refresh.enabled) matched (OnPropertyCondition)

Is there a work-around that I could put in place for now? Somehow force early creation of ContextRefresher?

And is should my issue with RefreshListener be a separate issue?