пардон, не заметил, что уже пробовали

Ага, это не работает для вызовов внутри класса

судя по ответам на SO можно погрузиться в сам AspectJ и перехватывать обращения к филдам. Spring AOP так не умеет, он только вызовы методов перехватывает. но это же прям черная магия :)

  public MyClass getThis() {
    return this;
  }

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

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

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

прототип выглядит вот так:
https://i.postimg.cc/cL68Z9tX/image.png

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

А какую проблему именно аспекты у вас решать будут ?

проблему наличия в прикладном коде кода генерации событий :)

Что такое прикладные классы ? :)

сама генерация событий будет вынесена в аспект. в прикладном классе только его прикладная логика

ну... "бизнесовые" которые. в которых полезный код

Но событие это же тоже может быть часть бизнес логики разве нет ?

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

То есть aspectj

событие - это следствие бизнес-логики. что с этим событием потом будут делать остальные компоненты системы - не ответственность объекта, который вызвал это событие

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

Да

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

а чем подход инджектить именно в сервисы EventPublisher который и будет дальше уже кидать ивент через спринг не подходит ? (делали так в проекте - было норм - единственное что учитывать нужно это поведение @Transactional)

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

один консерн