BeanPostProcessor вызывается для каждого бина до и после инициализации и может изменить или заменить объект — так появляются прокси для @Transactional, @Async, AOP и обрабатываются @Autowired, @PostConstruct.
А ещё BPP сам создаётся рано, и его зависимости не проходят через другие BPP
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Где в цикле: после создания объекта и внедрения зависимостей контейнер вызывает для каждого бина:
sottopostProcessBeforeInitialization(bean, name) у всех BeanPostProcessor;@PostConstruct, afterPropertiesSet, initMethod);postProcessAfterInitialization(bean, name) — результат и становится бином в контексте.Что на них построено:
AutowiredAnnotationBeanPostProcessor — внедрение @Autowired, @Value;CommonAnnotationBeanPostProcessor — @PostConstruct, @PreDestroy;AbstractAutoProxyCreator (AOP) — в after-фазе оборачивает бин прокси, если к нему применимы аспекты: @Transactional, @Async, @Cacheable. Поэтому в контексте лежит не ваш объект, а прокси.BeanFactoryPostProcessor работает раньше — когда есть только определения бинов (BeanDefinition), объектов ещё нет. Может менять метаданные: PropertySourcesPlaceholderConfigurer подставляет ${...}, ConfigurationClassPostProcessor разбирает @Configuration и @Bean.
Свой BPP — для инфраструктуры: регистрация бинов определённого типа в реестре, обёртка метриками. Подводные камни: BPP создаются до остальных бинов, поэтому бины, от которых зависит BPP, создаются рано и могут не получить прокси (сообщение «is not eligible for getting processed by all BeanPostProcessors»).
Один верный вариант. Подумайте, потом откройте ответ.
События приложения и @EventListener, FactoryBean, Aware-интерфейсы, порядок бинов (@Order/@DependsOn) и отложенное получение (ObjectProvider/@Lazy/@Lookup).
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.