Да Руслан правильно сказал,нужно прописать имена сервисов в application/bootstrap yml, и в межсервисной коммуникации обращаться по этим именам

И не обязательно чтобы имя контейнера совпадали с именем в yml

Да, действительно. Проверил - не только имя контейнера, но и имя сервиса вполне успешно резолвится в нужный айпи. Так что можно и hostname не прописывать.

Всем привет, подскажите пожалуйста как лучше было бы подступиться к следующей проблеме средствами Spring: раз в день на определённый endpoint прилетают данные в виде json, но в рандомном порядке, мне нужно как-то сохранить их и потом в нужном порядке отправить на свои endpoint’ы. Есть ли возможность как-то настроить Scheduler или может ещё какие-то средства, например, чтобы он выстраивал запросы в определенный порядок, и ничего дополнительно сохранять не пришлось бы? Заранее спасибо за помощь!

Шедулинг по крону как такой в спринге есть из коробки. Гулить в сторону аннотации @scheduled

Но возможно сохранять всё-таки стоит на случай внезапных падений приложения/проблем с сетью/etc

1) По какому принципу определять порядок отправки? (headers, по информации в теле, по ещё каким метаданным)
2) "... и потом в нужном порядке отправить...": потом - это когда?

Порядок в зависимости от файла, там получается одни зависят от других, но зависимые могут прийти раньше.
Потом - была мысль с разницей в час, когда все файлы точно придут

#change #petition #sign_it
https://www.change.org/p/%D0%BF%D1%80%D0%BE%D1%82%D0%B8%D0%B2-%D0%B8%D0%B7%D0%BE%D0%BB%D1%8F%D1%86%D0%B8%D0%B8-%D1%80%D0%BE%D1%81%D1%81%D0%B8%D0%B9%D1%81%D0%BA%D0%BE%D0%B3%D0%BE-%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82%D0%B0

попрошу всех кому не сложно репостнуть в другие паблики. Да маловероятно, что власти полностью поменяют свое решение, но возможно принятие этого законопроекта отложиться на год или два.

Ребята, как в spring+junit5 выполнять тесты с @Value-пропертями из тестового property-файла? Не могу запустить никак. Не понимаю, в чём прикол, уже полгугла и sof переворошил.

Самое простое - запускать тесты с определенными профилем через

@ActiveProfiles("test")

Тогда проперти из файла application-test.yml/properties будут подтягиваться как обычно

@ActiveProfiles("test")

Нет Спринг-бута.

Тогда можно попробовать

PropertySource("classpath:foo.properties")

Вот на СО есть ещё кучка советов) https://stackoverflow.com/questions/9259819/how-to-read-values-from-properties-file

PropertySource("classpath:foo.properties")

Чем отличается от того, что я написал?

А, так тут не в value беда. Тест на поднятие контекста же тоже падает.

Он даже пишет:

java.lang.IllegalStateException: Neither GenericXmlContextLoader nor AnnotationConfigContextLoader

Те тест не может подгрузить контекст. Сначала надо решить эту проблему. Потом уже пытаться value считать. Опять-таки эксперты с СО говорят, как это починить и даже ссылки на официальную доку приводят https://stackoverflow.com/questions/26055876/spring-testing-and-maven/26056103

java.lang.IllegalStateException: Neither GenericXmlContextLoader nor AnnotationConfigContextLoader

Но мне не нужны никакие бины из контекста, только проперти. Мне что, пустой @Configuration файл ему скормить? Как-то глупо.

По мимо самописных бинов  в контексте так же висит кучка бинов самого спринга, например PropertyPlaceholderConfigurer, PropertSource и прочие, которые отвечают за считывание проперти файлов.

Получить кусок функционала из контекста без создания этого контекста не получится.

Но вполне можно сделать контекст, в котором будут только бина, отвечающие за считывание проперти файлов.

а как лучше получать текущего авторизованного пользователя в микросервисах spring cloud?
Например, мне нужен текущи пользователь в book service:
1. начиная от gateway передается токен вниз к другим сервисам, p.s токен в gateway проверился spring security и валидный
2. взяв этот токен в book service я делаю запрос к auth-user-service, что-то типа findUserByToken(String token):User
получаю этого юзера
Это нормально, не bad practise?

Если jwt, то можно в токен всю нужную инфу про пользователя записать.

Тут в целом нет правильного ответа.
Если не напрягает "лишний запрос" в auth сервис (те лишняя нагрузка на сеть, лишние возможные отказы и все такое) - то вперёд.
Но возможно тебе не нужна вся информация о пользователе, а только его id и роли, например. Это можно зашить в payload токена.
Никто не мешает держать в пейлоаде токена лишь часть информации о пользователе, а полную информацию держать где-нибудь отдельно, так как она редко нужна

понял, спасибо вам 👍