Мой BeanPostProcessor не работает в Spring Boot

Я обычно использую аспекты для этого

@Aspect
public class TimedAspect {

    @Around("@annotation(some.thing.Timed)")
    public Object timeSomething(ProceedingJoinPoint joinPoint) throws Throwable {
        final long before = System.nanoTime();
        final Object returnValue = joinPoint.proceed()
        final long after = System.nanoTime();
        System.out.println("Method worked: " + (after - before) + " nano seconds");
        return returnValue;       
    }
}

по времени

package some.thing;

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Timed {


}

зависимость:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

общая информация о весеннем АОП

Весенний АОП

(я не пробовал, если этот код работает, скопируйте вставленные вещи из моего проекта)

Вы перебираете все методы, но возвращаете bean-компонент, если первый метод не имеет аннотации Timing:

for (Method method : methods) {
    if (method.isAnnotationPresent(Timing.class)) {
        Object proxy = ...
         return proxy;
     } else {
         return bean;
     }

Это означает, что вы создадите свой собственный прокси только в том случае, если первый метод, который вы найдете в аннотации.

Вы можете избавиться от предложения else и позволить вашему return bean после цикла for обрабатывать случай, когда ни один метод не имеет аннотации.

Во-первых, такой функционал уже есть. Spring Boot интегрируется с инфраструктурой Micrometer, которая допускает такой тип поведения (Spring Boot 1.x использует метрики dropwizard с дополнительной поддержкой бэкпорта микрометра, оба допускают этот декларативный стиль аннотаций).

Здесь является соответствующей главой документации микрометра.

На сегодняшний день это лучший вариант, который я знаю, однако, если вы все еще предпочитаете делать свои собственные (причина может заключаться в том, что все эти измерительные платформы поддерживают некоторую математическую модель (со скользящим окном и всем остальным) вокруг метрик, и если вы хотите что-то более напоминает профилирование для целей отладки или что-то в этом роде, тогда вы можете подумать о том, чтобы сделать что-то свое).

Теперь слово о Spring AOP, предложенное другими ответами. Я (и это только мое мнение) считаю, что в данном случае использование bean-постпроцессоров имеет преимущество перед АОП. Во-первых, возможно, вы вообще не используете Spring AOP, только обычный Spring. Вторая причина выбрать этот стиль реализации — это производительность, АОП добавляет довольно много вызовов в стек. Очевидным преимуществом АОП является простота реализации.

Итак, предположим, вам нужен способ BPP:

Я думаю, прежде всего, вы должны проверить, что постпроцессор Bean "распознается" весной во время запуска приложения.

Чтобы проверить это, вы можете создать конструктор без аргументов в BPP и напечатать там что-то вроде «Привет из BPP» или использовать отладчик.

Теперь, что касается предлагаемой реализации: Вам нужно перебрать методы и создать прокси только один раз. Нет смысла создавать прокси через прокси через прокси.... Таким образом, представленный код неверен.

Я думаю, вам следует перебрать методы, подготовить список методов и запомнить этот набор, а затем создать прокси, который будет иметь метод invoke, который будет проверять, находится ли метод в наборе методов, и если да, то делать магию прокси, иначе просто делегировать вызов базовому компоненту.

Две вещи, которые вы должны иметь в виду, когда идете по этому пути:

• Прокси не будет работать с реальными классами, только с интерфейсом. Если у вас есть класс и не работает интерфейс, вам нужно возиться с CGLIB

• Другие постпроцессоры компонентов также могут обернуть ваш компонент каким-либо прокси, например, что, если вы измеряете метод, аннотированный @Transactional?