Looking at the implementation of ControllerAdviceBean#findAnnotatedBeans it requires an ApplicationContext but only for the purpose of retrieving the BeanFactory.
It would be better if such method did not require the application context as it forces all callers to also require it.
Comment From: sbrannen
Would the addition of the following method suit your needs?
public static List<ControllerAdviceBean> findAnnotatedBeans(ListableBeanFactory beanFactory) {
// ...
}
Comment From: snicoll
In addition or in replacement, yes. But now that I see the requirement on ListableBeanFactory, I am not so sure anymore. Perhaps @jhoeller can chime in as we've discussed many times the boundary between the context and the bean factory.
Comment From: jhoeller
Generally speaking, it makes sense to require the most minimal interface possible, and we do use ListableBeanFactory in other signatures. From that perspective, it seems sensible to introduce such an overloaded version of findAnnotatedBeans.
The only argument for ApplicationContext is that a future version of the implementation of that method might want to consider other context facilities not available on ListableBeanFactory, which it can do without any signature change then. This might not even be on ApplicationContext itself but rather on a downcast such as WebApplicationContext or ConfigurableApplicationContext which is only a reliable assumption when given the context instance (rather than possibly the internal BeanFactory used within the context). However, even if callers commonly have the ApplicationContext available and can provide it for such future-proofing, it still makes sense to provide a minimal overload for the method with its current algorithm. It ultimately depends on the intended callers.