на боевом стенде это собиралось часов 6

добавь опцию сбора хип-дампа в параметры jvm

На OpenJDK/Hotspot — точно из heapdump можно получить threaddump.

Не стоит забывать и про coredump — из него можно получить и heapdump и threaddump и много чего ещё

Товарищи, специалисты по спрингу на месте?

не очень понтная разница в SingletonBeanRegistry.registerSingleton и ConfigurableListableBeanFactory.registerResolvableDependency

С дефолтной реализацией

По факту в контексте я получу в любом случае синглетон, если не переопределю скоуп

а как ты вляпался в такой вопрос? Хоть узнаю куда не стоит лезть :)

Генерю rest клиентов в рантайме через jdk dynamic proxy😁

А, ну да, это мы знаем- кодогенерация это плохо

Нет, все работает как надо, но в первом варианте с небольшими сайд эффектами

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

Все таки хотелось бы узнать мнение спринговых специалистов)))

registerResolvableDependency более тонкая штука. Туда можно класть ObjectFactory, кроме того, там указывается тип зависимости, т.е. там можно ограничить возможности для связывания в отличие от registerSingleton

Да, это я понимаю, что класть туда можно либо реализацию ObjectFactory, либо объект с тем же типом, который продекларирован первым параметром

Подкину подробностей с вашего позволения

есть  СЕРВИС_№1 и СЕРВИС_№2.  в СЕРВИСе_№1 генерятся REST клиенты в рантайме для доступа к API СЕРВИСа_№2. По факту это динамические прокси, которые шлют http запросы на корневой сервлет СЕРВИСа_№2 (CXF сервлет). Так вот я эти прокси пробую регистрировать в бин фактори пост процессоре с помощью двух подходов. В первом случае (registerSingleton) эндпойнты СЕРВИСа_№2 становятся доступны через base_url СЕРВИСа_№1 - ЭТОГО НЕ ДОЛЖНО БЫТЬ. Во втором случае такого эффекта нет и прокси работают как обычные http клиенты

Проблема - оголяются эндпойнты СЕРВИСа_№2

СЕРВИС - это микросервис или класс, аннотированный @Service?

Похоже, что микросервис)