Intellij Idea, Java, Spring — Troubleshooting

Intellij Idea, Java, Spring — Troubleshooting

Type specified for TypedQuery [ru.knastnt.app.MyClass] is incompatible with query return type [class ru.knastnt.app.MyClass]

Такое случается при дебаге и решается с путём исключения из pom.xml зависимости spring-boot-devtools.


Can’t load camunda cockpit with error in console:

It was not able to load the following file ‘app/plugin.js’

Проблема описана здесь https://jira.camunda.com/browse/CAM-10738 и решением является:

— либо запуск с использованием Shorten command line:

— либо удаление из .idea/workspace.xml строки <property name=»dynamic.classpath» value=»true» />


@JsonAnySetter not works. @JsonAnySetter не работает на вложенных объектах.

С этой проблемой я мучился несколько дней! Оказалось, что при объявлении переменной помеченной аннотацией @JsonAnySetter , её нужно обязательно инициализировать! =)

@JsonAnySetter
private Map<String, MyObject> myObjects= new HashMap<>();

Диблирующиеся значения в списке @OneToMany

Воспроизводится при EAGER загрузке. Предлагают заменить List на Set: https://stackoverflow.com/questions/20749806/duplicates-in-onetomany-annotated-list


Почему не стоит делать JUnit тесты транзакционными

У меня давно сформировалось такое мнение, но причины этого как-то уже позабылись. Буду пытаться восстановить их здесь:


@Autowired not work

На самом деле он вполне себе «work», но при дебаге поле равно null. Например, я пытался найти решение проблемы примерно такими запросами:

controller enhancerBySpringCGLIB
dispatcher servlet uses cglib proxy of controller
why spring controller behind proxy
why spring dispatcher servlet uses proxy
Spring @Autowired Field Null

Суть в том, что при обращении к спринговому контроллеру постоянно вылетал NPE. Потом оказалось, что потому что @Autowired поля равны null. Но ведь контекст не смог бы запуститься, поэтому их явно кто-то делает null после инициализации контекста (и если поставить брейкпоинт в постконструкторе, то эта теория подтверждается). Потом оказалось, что диспатчер сервлет обращается не к бину контроллера, а к его CGLIB-прокси, и он не отдаёт оригинальное содержимое полей, а вместо этого возвращает null. Затем выяснилось, что с остальными контроллерами всё нормально. Пакеты в импортах — одинаковые, разниц в используемых аннотациях нет. Причём, тесты проходят вполне себе успешно. Совершенно непонятно что за хрень!

Проблему удалось обнаружить здесь: https://stackoverflow.com/a/65031345/11269954

Да, да, я потерял пол дня потому, что мои методы контроллера были private ?

(Просмотрено 525 раз, 1 раз за сегодня)

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *