1. Инспекция bean в ApplicationContext
Если вы впервые сталкиваетесь с тем, что Spring «вернул не тот объект», это ощущается как фокус из цирка: вы ожидали увидеть ReportingService, а в отладчике внезапно какое‑то jdk.proxy2.$Proxy42. В этом месте важно успокоиться: контейнер не издевается, он просто делает то, что мы сами попросили (явно или неявно) через свои механизмы расширения.
Здесь полезно устроить маленький «рентген» контейнера и посмотреть, как proxy появляется внутри ApplicationContext.
Ключевая идея здесь такая: Spring хранит и раздаёт не «объект, который вы создали», а «объект, который получился после всей контейнерной обработки». И именно поэтому инспекция — полезный навык: когда поведение странное, первое, что хочется понять — «кто реально стоит между мной и логикой?».
Для визуализации полезно держать в голове такую цепочку:
flowchart TD A["Bean создаётся контейнером"] --> B["BeanPostProcessor(ы)"] B --> C["Итоговый bean instance в контексте (может быть proxy)"] C --> D["Этот instance получают другие beans и ваш код"]
BeanPostProcessor уже знаком как часть startup pipeline. Здесь он нужен как легальный крючок, на котором контейнер может заменить исходный объект обёрткой.
2. Контракт для прокси: интерфейс
Чтобы JDK dynamic proxy вообще мог существовать, ему нужен интерфейс, потому что он умеет «притворяться» интерфейсом, но не умеет «становиться» конкретным классом. Поэтому начнём с очень маленького, аккуратного шага: выделим контракт для отчётного сервиса. Даже если у вас уже есть ReportingService, добавить интерфейс — это нормальная эволюция, а не «интерфейс ради интерфейса» (тут у нас есть прикладная цель: proxy-модель).
Создадим интерфейс ReportOperations (пакеты — как в нашем проекте ContextFlow):
package com.example.contextflow.application.reporting;
public interface ReportOperations {
// Контракт: вызывающий код зависит от интерфейса, а не от конкретной реализации
String generate();
}Теперь сделаем target object — обычную реализацию. Здесь специально нет никакой магии: просто метод, который возвращает строку.
package com.example.contextflow.application.reporting;
public class ReportingService implements ReportOperations {
@Override
public String generate() {
// Простая реализация, чтобы в примере было видно: логика живёт в target
return "daily-report";
}
}Обратите внимание на тонкий, но важный смысл: контракт для вызывающего кода — ReportOperations, а ReportingService — просто конкретная реализация. Если завтра ReportingService начнёт быть проксированным, вызывающий код не должен от этого страдать. Он и так живёт через интерфейс.
Теперь нужен максимально прозрачный способ увидеть саму подмену bean instance. Поэтому пойдём через BeanPostProcessor: он уже стоит на пути контейнерной обработки и как раз показывает момент, когда исходный bean перестаёт быть тем объектом, который контейнер отдаёт наружу. Это не новый повседневный рецепт “делать proxy руками в Spring”, а учебный рентген той же substitution-модели, на которой строится и AOP-инфраструктура.
3. Proxy через BeanPostProcessor
Сейчас будет момент «ага!». Мы напишем свой BeanPostProcessor, который после инициализации конкретного bean-а вернёт не исходный объект, а JDK proxy вокруг него. Это будет учебный, максимально прозрачный пример: proxy просто напечатает «before» и замерит время выполнения. Бизнес-логика при этом останется в target object.
Скелет BeanPostProcessor выглядит так: фильтруем только нужный bean по имени и по типу, а остальное не трогаем.
package com.example.contextflow.support.postprocessor;
import com.example.contextflow.application.reporting.ReportOperations;
import org.springframework.beans.factory.config.BeanPostProcessor;
import java.lang.reflect.Proxy;
public class ProxyWrappingBeanPostProcessor implements BeanPostProcessor {
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) {
// Важно: BPP видит *все* beans, поэтому фильтрация обязательна
if (!beanName.equals("reportingService") || !(bean instanceof ReportOperations target)) {
return bean; // Все остальные beans не трогаем
}
// Возвращаем proxy вместо исходного объекта (target остаётся жить "внутри")
return Proxy.newProxyInstance(
ReportOperations.class.getClassLoader(),
new Class
[]{ReportOperations.class},
(proxy, method, args) -> {
// Техническая обвязка вокруг вызова: измеряем время
long started = System.nanoTime();
try {
// Важно: реальную логику выполняет target
return method.invoke(target, args);
} finally {
// Логируем "снаружи" — это поведение proxy, а не target
System.out.println("Took(ns): " + (System.nanoTime() - started));
}
}
);
}
}Если вас смущает слово invoke и рефлексия — это нормально. Здесь не нужно становиться экспертом по reflection. Нам важна идея: есть объект-перехватчик, который решает, что сделать вокруг вызова. Spring AOP делает то же самое, просто более аккуратно и массово.
И ещё одна важная деталь. Мы используем метод postProcessAfterInitialization, потому что хотим показать: bean уже создан, зависимости уже внедрены, init-логика уже отработала, и только потом контейнер говорит: «а теперь давай-ка я тебя заверну». Это хорошо стыкуется с mental model жизненного цикла.
4. Подключаем демо в конфигурации Spring
Здесь нам важнее прозрачность, чем «красота» конфигурации, поэтому сделаем отдельный маленький конфиг для инспекции proxy. Так проще увидеть сам факт подмены bean instance.
Вот конфигурация, которая регистрирует и target bean, и наш BeanPostProcessor:
package com.example.contextflow.config.core;
import com.example.contextflow.application.reporting.ReportOperations;
import com.example.contextflow.application.reporting.ReportingService;
import com.example.contextflow.support.postprocessor.ProxyWrappingBeanPostProcessor;
import org.springframework.beans.factory.config.BeanPostProcessor;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class ProxyInspectionConfig {
@Bean
ReportOperations reportingService() {
// Возвращаем контракт (интерфейс), а не реализацию — так proxy-модель "нативнее"
return new ReportingService();
}
@Bean
static BeanPostProcessor proxyWrappingBeanPostProcessor() {
// Регистрируем BPP: именно он подменит bean на proxy после инициализации
return new ProxyWrappingBeanPostProcessor();
}
}BeanPostProcessor здесь объявлен как static @Bean: для ранней инфраструктуры это хорошо сочетается с уже знакомой логикой startup pipeline и не размывает границу между обычными beans и специальными контейнерными механизмами.
Здесь есть полезный приём: @Bean возвращает ReportOperations, а не ReportingService. Мы заранее фиксируем опорный тип — интерфейс. Если в проекте у вас компонент‑сканирование и @Service, то принцип остаётся тем же: инъектимся по контракту, а не по конкретному классу, когда это разумно.
5. Проверяем runtime-тип bean из контекста
Здесь нам нужны те же базовые проверки, что и у любого proxy: реальный runtime-class, контракт интерфейса и один быстрый тест на JDK proxy. Не надо гадать по имени bean-а — надо посмотреть, что контейнер действительно отдал.
Сделаем маленькое приложение для запуска. Это может быть отдельный main(), не обязательно переписывать основной запуск ContextFlow.
package com.example.contextflow;
import com.example.contextflow.application.reporting.ReportOperations;
import com.example.contextflow.config.core.ProxyInspectionConfig;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
public class ProxyInspectionApp {
public static void main(String[] args) {
// Контекст создаём руками, потому что это учебный запуск/инспекция
try (var ctx = new AnnotationConfigApplicationContext(ProxyInspectionConfig.class)) {
// Забираем bean по контракту — так и должно быть в DI
ReportOperations ops = ctx.getBean(ReportOperations.class);
// Диагностика: смотрим runtime-класс (скорее всего, это будет proxy)
System.out.println(ops.getClass().getName()); // jdk.proxy2.$Proxy...
// Бизнес-вызов проходит через proxy и делегируется в target
System.out.println(ops.generate()); // daily-report
}
}
}С высокой вероятностью вы увидите что-то вроде jdk.proxy2.$Proxy12 (точный номер будет разный) и затем строку daily-report. Но важнее другое: между этими строками у вас появится вывод времени из proxy:
Took(ns): 12345
daily-reportЗначит, вызов действительно прошёл через proxy, а не напрямую в target.
Теперь давайте добавим пару проверок типов. Это ровно то, что нужно для реальной инспекции: понять, что за объект лежит в контексте, и не перепутать контракт с реализацией.
import com.example.contextflow.application.reporting.ReportOperations;
import com.example.contextflow.application.reporting.ReportingService;
import java.lang.reflect.Proxy;
// Проверяем: это вообще proxy-класс?
System.out.println(Proxy.isProxyClass(ops.getClass())); // true
// Контракт (интерфейс) соблюдён — это самое важное
System.out.println(ops instanceof ReportOperations); // true
// А вот реализация — нет, потому что это не ReportingService, а обёртка
System.out.println(ops instanceof ReportingService); // falseИменно этого мы и добивались: логика остаётся в ReportingService, но из контекста приходит proxy-instance. Если зависимости проектируются по интерфейсу, бизнес-код спокойно продолжает работать по контракту.
6. getBean() по имени и runtime-тип
Имя bean-а не гарантирует точный класс объекта. В Spring это скорее «слот», а не «паспорт экземпляра».
Покажем это без лишней философии: достанем bean по имени и сравним поведение.
// Достаём bean по имени — это именно "слот", а не обещание про точный класс
Object bean = ctx.getBean("reportingService");
System.out.println(bean.getClass().getName()); // jdk.proxy2.$Proxy...
System.out.println(bean instanceof ReportOperations); // trueИ теперь самый соблазнительный (и самый опасный) шаг — «ну раз это reportingService, давай я его приведу к ReportingService». Давайте сделаем это аккуратно, через try/catch, чтобы увидеть реальность, а не просто получить красный экран.
try {
// Опасный каст: в случае JDK proxy это почти наверняка приведёт к ClassCastException
ReportingService impl = (ReportingService) bean;
System.out.println(impl.generate());
} catch (ClassCastException ex) {
// Здесь мы фиксируем факт: контейнер вернул обёртку, а не реализацию
System.out.println("Cast failed: " + ex.getClass().getSimpleName()); // ClassCastException
}Смысл не в том, чтобы запомнить “будет ClassCastException”. Смысл в дисциплине: если вы на уровне кода начинаете кастовать beans к реализации, вы сами ломаете себе proxy-модель. Контейнер может вернуть обёртку, и вы обязаны держать это в уме. Здесь работает то же правило, что и с любым proxy: проверка по контракту (instanceof ReportOperations) устойчива, а попытка упереться в exact class быстро ломается.
7. Где держать диагностику контейнера
Очень легко после таких экспериментов сделать ужасную вещь: начать таскать ApplicationContext по всему приложению и в каждом сервисе писать ctx.getBean() «чтобы точно было то, что нужно». Это уже знакомый запах из Дня 9: service locator вместо DI.
Чтобы остаться в рамках здоровой архитектуры ContextFlow, можно придерживаться простого правила. Инспекция контейнера — это инфраструктура или диагностика, а не бизнес‑логика. Значит, ей место либо в support.*, либо в стартовом/сценарном коде, но не в application.service.
Если у вас уже есть отдельный инфраструктурный бин для диагностики контекста, его удобно расширить минимальной утилитой «покажи runtime class». Например, в духе:
package com.example.contextflow.support.diagnostics;
import org.springframework.context.ApplicationContext;
public class ProxyDiagnostics {
private final ApplicationContext ctx;
public ProxyDiagnostics(ApplicationContext ctx) {
// Контекст сохраняем только для инфраструктурной диагностики, не для бизнес-логики
this.ctx = ctx;
}
public void printRuntimeType(String beanName) {
// Инспекция: достаём bean по имени и печатаем его runtime-тип
Object bean = ctx.getBean(beanName);
System.out.println(beanName + " -> " + bean.getClass().getName());
}
}Это не идеальная «продовая» утилита (и мы не делаем из этого отдельный продукт), но методически она важна: вы держите «умение смотреть в контейнер» в одном месте, а не размазываете getBean() по бизнес‑сервисам. Бизнес‑сервисы при этом продолжают получать зависимости через конструктор, как мы учили ранее.
А если вы хотите вообще без ApplicationContext в конструкторе (что часто приятнее), можно оставить диагностику на уровне main/scenario runner, где getBean() — допустимый инструмент именно как bootstrap/inspection API.
8. Схема: proxy и target
Иногда полезно остановиться на секунду и просто посмотреть на картинку. Мы не «ускоряли отчётность магией Spring», мы сделали простую, почти механическую штуку: вставили объект на пути вызова.
flowchart LR A["Ваш код: ctx.getBean(ReportOperations)"] --> B["Proxy (JDK dynamic proxy)"] B -->|делегирование вызова| C["Target: ReportingService"] B --> D["Техническая обвязка: timing/logging"]
Если вы запомните эту схему и добавите к ней мысль “proxy появляется через контейнерные extension points (например, BPP)”, то 80% «магии Spring» перестанут быть магией и станут инженерией.
9. Типичные ошибки при инспекции proxied beans
Ошибка №1: проверять тип через getClass() == ... и строить на этом логику.
Когда вы начинаете сравнивать точный класс объекта, вы фактически запрещаете контейнеру оборачивать этот объект. В мире proxy это почти всегда плохая идея: контейнер может вернуть другой runtime‑класс, но объект при этом полностью корректен по контракту. Лучше опираться на интерфейс или базовый тип, а getClass() оставлять как диагностический инструмент, а не как условие в бизнес-логике.
Ошибка №2: пытаться кастовать интерфейсный proxy к конкретной реализации.
Для JDK dynamic proxy это гарантированная ловушка: прокси реализует интерфейс, но не является экземпляром класса реализации. Самый правильный способ избежать этого — не требовать реализации там, где вам нужен контракт. Если очень хочется «достать target», это уже отдельная инфраструктурная история, и её нельзя превращать в повседневную привычку.
Ошибка №3: писать BeanPostProcessor, который проксирует «всё подряд».
Новичку кажется: “раз это прикольно, давайте завернём все beans”. После этого приложение начинает вести себя странно, ломаются типы, появляется куча неожиданных эффектов, а дебаг превращается в хоррор. В учебных (и реальных) проектах проксирование должно быть точечным: фильтрация по имени, типу, аннотации, пакету — что угодно, лишь бы не превращать контейнер в мясорубку.
Ошибка №4: переносить контейнерную диагностику в бизнес‑сервисы.
Как только в OrderPlacementService появляется ApplicationContext ctx “для удобства”, вы сделали шаг к service locator и спрятанным зависимостям. В ContextFlow мы осознанно держим такие вещи в support.* или в bootstrap-коде. Иначе вы теряете главный плюс DI: прозрачность зависимостей через конструктор.
Ошибка №5: считать, что proxy «переписывает» target object или “добавляет в него код”.
Proxy не обязан менять target. Он может вообще не трогать исходный объект, а просто стоять между вами и ним. Поэтому, когда вы дебажите, важно различать: “внутри есть объект с логикой” и “в контейнере вам выдали обёртку”. Эта ясность экономит часы жизни — а иногда и целые нервные клетки (их, говорят, не восстанавливают, но программисты всё равно пытаются).
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ