Анатомия Spring Proxy: кто и зачем подменяет ваши бины
Совершенно точно каждый из нас (java-разработчиков), когда-либо встречал в своей жизни понятие "прокси" из Spring. Кто-то на уровне подготовки к собесам, а-ля "@Async создает прокси", а кто-то споткнувшись на self-invocation в собственном классе.И большинство, собственно как и я до определенного момента, часто удовлетворяются простым объяснением: "Spring использует AOP, создает прокси вокруг нашего бина и тем самым добавляет дополнительную логику до и после вызова метода."Но на мой взгляд этого понимания крайне недостаточно в современных условиях. Сегодня мы разберемся:Что такое этот $$SpringCGLIB$$0, который неожиданно оказался вместо моего класса? Кто и в какой момент решил заменить мой бин? Откуда берутся загадочные Advisor и TransactionInterceptor, которые я никогда не создавал? Почему порядок выполнения аспектов именно такой? И что вообще физически находится внутри этого самого Proxy? Приглашаю Вас шаг за шагом проследить путь одного объекта: от обычного Java-бина до полностью собранного Spring Proxy. По дороге заглянуть в исходники Spring и посмотреть, как рождаются Advisor'ы, как они сортируются, кто собирает прокси и из каких объектов он на самом деле состоит. Заглянуть