Здравствуйте!
Я так понимаю, нужно сделать рест сервис: контроллер, сервис, репозиторий
Каждый протестировать в виде unit теста, мокируя зависимости друг друга
Репозиторий пишет в БД. Возможно, здесь можно обойтись embedded БД. Это все нужно уточнять

Спросить надо не у рандомных чуваков в чатике, а у работодателя.

Все привет,

Коллеги, подскажите:

Есть ямлик:

 my-services:
   service1:
     prop1: p1
     prop2: p1
   service2:
     prop1: p3
     prop2: p4
...
неограниченной длины (то есть сервисов в нем может быть скажем 100)

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

Например, если в конфиг классе один бин вида:

   @Bean
   public MyBean myBean() {
     return new MyBean(prop1, prop2);
   }

то для 100 сервисов должно создаться 100 бинов с именами вида "serviceX_myBean"

Вопрос такой:
Можно ли это сделать без всяких BPP ? И как лучше вообще поступить?

Всем спасибо!

А что в данной задаче значит сервис? Это типа отдельные приложения (контексты) или как бины? Пока читается как spring xml, но в ямле смешанный с конфигами )

Привет, может кто-то подскажет, нужно писать тесты для парсера. Если да, то каким образом они должны работать?

В ямле есть массивы.
Типа такого:

services:
  - name: service1
    prop: prop1
  - name: service2
    prop: prop2

Правда, если все пропы разные, то я не уверен, что так получится.

Это имена других сервисов, которые будут пользоваться нашей либой. Идея в том, что либа может использоваться в service1 и, например, транзитивно тянуться из другой зависимости. Соотв конфиги будут перетирать друг друга.
Но к вопросу это отношение не особо имеет.

В терминах вопроса сервис - это ключ с особым набором значений заранее известных пропертей (prop1 и prop2 в примере). В реальности их много, они вложены друг в друга и пр

Хочется формировать отдельные инстансы конфиг класса для каждого сервиса

Если совсем коротко и обобщенно:

Как создавать бины из джава конфига на основании мапы пропертей произвольного размера, где одна запись - валидный набор пропертей для одного конфига

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

Есть ли причина делать это "без всяких BPP"? Пока по описанию задача выглядит, как идеально ложащаяся на BeanDefinitionRegistryPostProcessor.

ну если в конфиге по 10 бинов и собирать их руками в бпп - не оч выглядит

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

одинаковые. просто был один нормальный конфиг, теперь в эти кишки лезть) ну ладно. Спасибо за ответ!

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

Ну а как еще? Проперти-файлы - это просто набор свойств. Набор свойств в набор бинов без кода не превратить. Ваш более генерализированный вопрос "Как создавать бины из джава конфига на основании мапы пропертей произвольного размера" имеет тот же ответ. Кто должен превратить эту мапу в набор бин-дефинишинов? Если не код, написанный для этого.

Единственная альтернатива тут - XML-конфиги бинов. Там их в бин-дефинишины тоже превращает некий код, только код для этого уже написан и является частью фреймворка. :)

Подскажите а JPA умеет работать с полнотекстовым поиском PostgreSQL ?
Например  какого типа поле у сущности должно соответсвовать tsvector ?

I created function in postgres, and just called it from @query native.

Да, помню гуглится неплохо

Можно ещё kotlin dsl заюзать :)

Это еще один способ создавать бины в Спринге? Или это просто @Configuration, только на Котлине?

Не, это реинкарнация groovy dsl