Понял. От меня ускользнуло, что инстанс Cfg не создается. Чертова магия :)
По-прежнему считаю, что пример хорош. Можно использовать в качетве продолжения разговора про спринговые прокси на собеседованиях. Я вот точно возьму вашу статью на вооружение.
С помощью CGLib создается класс наследник и дальше все как положено: наследование, полиморфизм…
Все так. И ситуация эта отличается тем, что для аспектов наследник работает специальным образом, что заставляет код реального класса думать, что this — это он и есть. Другими словами, реализуется Proxy прямо как в учебнике. Если бы это было верно для конфигурации, то вызов a() из кода класса Cfg каждый раз печатал бы «here».
@Configuration
public class Cfg {
@Bean
public A a() {
System.out.println("here");
return new A();
}
@Bean
public B b(A a) {
// каноничная инъекция
return new B(a);
}
@Bean
public C c() {
// this - proxy, this.a() ~ ctx.getBean()
return new C(a());
}
}
Тут все по-настоящему, CGLib обертка не прикидывается, что уважает ООП.
Если бы было иначе, автор потобного кода мог нарваться на двойную инициализацию какого-нибудь дорогостоящего синглтона, но нет, спринг и таких бережет :)
По-прежнему считаю, что пример хорош. Можно использовать в качетве продолжения разговора про спринговые прокси на собеседованиях. Я вот точно возьму вашу статью на вооружение.
Все так. И ситуация эта отличается тем, что для аспектов наследник работает специальным образом, что заставляет код реального класса думать, что this — это он и есть. Другими словами, реализуется Proxy прямо как в учебнике. Если бы это было верно для конфигурации, то вызов a() из кода класса Cfg каждый раз печатал бы «here».
Тут все по-настоящему, CGLib обертка не прикидывается, что уважает ООП.
Если бы было иначе, автор потобного кода мог нарваться на двойную инициализацию какого-нибудь дорогостоящего синглтона, но нет, спринг и таких бережет :)