отправил.

Никогда не задумывался и тут возник вопрос, нормально ли описывать геттеры и сеттеры в интерфейсе?;) По факту ничего плохого не вижу. У кого какое мнение?

В этом есть какой-то функциональный смысл?

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

Незнаю нормально обьяснил или нет...

Да изначально кем-то это просто было не продуманно

Если для интерфейса они нужны, то почему нет. Интерфейс - это ж требование в функционалу, а не документация по классу.

согласен с вами)

Помогите советом. С Boot`ового приложения, через обычный restTemplate, идет обращение к Rest API тоже на спринг буте, между ними есть прокси. 2хх респонсы в json нормально читает, 4хх, во время чтения первого chunk`а, выбрасывает IO exception ConnectionReset by peer (DefaultResponseErrorHandler.getResponseBody).  В тоже время в ui сваггера можно прочитать респонс. Дело в проксе?

а что в логах прокси ?

Пока не смотрел там, грешил на апгрейд томката (9.0.37) но откат не помог

Привет всем, у меня есть вопрос. Кто-то может проянить некоторые моменты, связанные с реализацией моей задачи. В общем задача такая - пишу анонимный чат. Для матчинга юзеров я буду использовать серию запросов. 1) юзер шлет запрос, что он хочет в чат, на сервер приходит запрос,  id юзера падает в очередь. А далее сервер должен отправить юзеру  ответ с id комнаты(состоит, например из id-ов двух участников, между которыми дефис) для дальнейшего соединения по webSocket'y. Так вот, я понимаю, что без тредов тут не обойтись, а так как я в работе с ними не силен, то прошу совета, как мне верно организовать все это дело. Я понимаю, что у меня должен стоять scheduler, который, например, каждые пол секунды будет проверять очередь и чекать, есть ли там более двух id, если да, то он отсылает ответ с номером комнаты и удаляет их из очереди. В основе Sring

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

Да в том то и дело, что толковых примеров я не нашел, то ли руки не из того места, то ли плохо искал))
Но спасибо большое

можно начать с запроса - spring chat github, и увидеть много чатов, выложенных на гитхаб

можно поставить Киклок, подсоединить ему базу и он будет отдавать jwt

А зачем Киклок, если springboot будет сам с БД считывать и отдавать JWT?

Плюс в том, что тебе не нужно писать свой Authorization Server. Можно юзать готовый, который обновляется контрибьютерами. Я не настаиваю, посмотри, поспрашивай, могу ссыль дать на Киклок коммюнити, там можешь спросить. Ещё есть решение от Спринг коммюнити, но оно сырое. И я не слышал о том, что Спринг бут сам отдаёт jwt, если ты про access_token