объявлено два метода:
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 и вообще все "зеленое"
Обсуждают сегодня