Spring AOP. есть класс, на который натравлен аспект. В классе

объявлено два метода:
public MyClass getThis() {
return this;
}

public List<MyClass> getThat() {
return List.of(this);
}

В отладчике вызываю эти методы. getThis возвращает cglib-enhanced обертку, getThat - лист с оригинальным классом.

1) Это нормально?
2) Есть ли возможность заставить getThat возвращать лист с cglib-enhanced оберткой?

а где вы вызываете оба метода?

в стороннем классе, который получает MyClass как бин. ставлю точку останова и в watches отладчика гляжу. плюс есть тест, который проверяет эту же ситуацию уже кодом

интересный кейс 🙂 такое чувство, что причина в equals и hashCode бинов в контексте. При возврате this - спринг находит в контексте этот бин (предположение! а то налетят сейчас 🙂 ), а вот лист у тебя генерится каждый раз новый, соответственно он его найти в контексте не может и возвращает без прокси.

потому что даже при дебаге, при остановке в методе getThis() - this там не является прокси объектом и как бы возвращает метод НЕ прокси объект. А вот уже на другой стороне, сервис его вызывавший получает почему то прокси

Ну да, так это и работает

ну на самом деле не совсем очевидно. в какой момент НЕ прокси становится прокси?

А вам вообще зачем такой изврат? Это академическая задача или какая-то реальная проблема?

делаю подсистему событий на аспектах. мне не нравится, что для публикации событий нужно в прикладные классы инжектить applicationEventPublisher и явно вызывать у него создание эвентов и их публикацию. основная идея - создать аспект, в котором выделить логику перехвата вызовов, требующих генерации событий, и собственно самой генерации событий. чтобы прикладной код отдельно, события отдельно. прототип выглядит вот так: https://i.postimg.cc/cL68Z9tX/image.png так как аспектируемые объекты могут передавать this внутрь других классов, то есть риск вызова метода, на котором в аспекте назначен эдвайс, из объекта, не являющегося aоп-прокси. в конкретной текущей кодовой базе таких вызовов нет, но и подсистема событий со временем будет расширяться. дебажить такое продолбанное событие будет тем еще приключением, поэтому думаю, как защитится от этого изначально

Используйте compile time aspects

Compile-Time Weaving имеете ввиду?

Да

я ковырял в сторону Load-Time Weaving, но утонул в варнингах в логах. попробую покопать CTW, спасибо за наводку

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

не, речь не про код аспекта. вот есть у меня бин1, который используется где-то вовне. аспект следит за методом на этом бине1. бин1 внутри себя инжектит какой-то другой бин2. внешний объект вызывает эдвайснутый метод на бин1 (он по честному обернут в аоп-прокси), бин2 вызывает эдвайснутый метод на бин1 (а здесь пришел оригинальный this). первый вызов ловится аспектом, второй - нет

спасибо за совет. переход на чистый AspectJ и градль плагин io.freefair.aspectj.post-compile-weaving решили проблему. инстансы бинов совпадают, пропали проблемы с мокитовским spy и вообще все "зеленое"