Как я понял процесс построения бина выглядит следующим оьбразом:

1 Конструктор
2.BeanPostProcessor beforeInitialization
3.@PostConstruct
4.BeanPostProcessor afterInitialization

ну и постпроцессоров то куча.


В какой момент спринг заменяет бин на прокси если это требуется?

Когда я могу быть уверен, что это ещё не прокси?

Blazkowicz,

Получается, что в контексте сидят чистые бины, а при запросе к ioc контейнеру нам возвращается прокси. Причем не всегда насколько понимаю

Blazkowicz,

ты ж не будешь отрицать, что инициализация синглтонов и соответственно все постпроцессоры выполняются при поднятии контекста ?

Blazkowicz,

или я не понимаю глубинного смысла аоп в коре спринга

такс....я прозрел до того, что CGLIb и dynamic proxy это лишь способы реализации AOP.

fixxerquestioner,

Я буду отрицать. Бины в контексте могут быть ленивыми и инстанцироваться при первом обращении. А вот по существу вопроса могу сказать, что все корректно реализованные проксирующие пост процессоры делают проксирование в afterInitialization, поэтому вы в beforeInitialization и в @PostConstruct имеете "чистый" бин описанного в BeanDefinition класса.

а бывают некорректно написанные постпроцессоры в самом спринге? есть на это какой-то контракт на то в каком постпроцессоре вернется прокси, а в каком нет?

Atum1questionerКак я понял процесс построения бина выглядит следующим оьбразом:

1 Конструктор
2.BeanPostProcessor beforeInitialization
3.@PostConstruct
4.BeanPostProcessor afterInitialization

ну и постпроцессоров то куча.


В какой момент спринг заменяет бин на прокси если это требуется?

Когда я могу быть уверен, что это ещё не прокси?

тут все ответы :

chabapokquestionerЭто он сам руками вернул в afterInitialization проксю.
Я кстати так и не понял, что ему мешало это сделать в berforeInitialization.


если бы он возвращал в beforeInitialization проксю, то это было бы уже другой класс, на другом классе стоят другие аннотации, там другие переменные и тд и тп. Все последующие бинпостпроцессоры работали бы уже с этой проксей, а это совершенно другой обьект, другого класса.

Получается, вообще на этапе before возвращать другой обьект - это крайне плохая идея.

и чего получается?

всегда можно быть уверенным, что в beforeInitialization не прокся, а натуральный бин, а дальше нефига не понятно ?

Blazkowiczquestioner,

Я вот одного не пойму. Если АОП реализовано через инструментацию байт-кода без прокси. То по-вашему всё будет совсем иначе?


я просто пытался понять как гипотетически можно решить проблему, что при вызове метода объекта из того же самого объекта быть уверенным, что функциональность не пропадёт.

Atum1questioner,

использовать интерфейс ?! не?

не ферштейн к чему это