Можешь конечно, но это может привести к проблемам потенциальным. Поэтому нормальные линтеры определяют это как проблему. А вот отсутствие Autowired при constructor injection ни на что не повлияет. Как-то так.

+

Да, и самое главное, не дать допустить ему ошибку в этом самом переопределении.

Так и есть. У нас в проекте spring-аннотации, кроме конфиг-классов, есть только у контроллеров

@Bean public A a() { return new A(b(), e()); }
@Bean public B b() { return new B(c(), d()); }
@Bean public C c() { return new C(); }
@Bean public D d() { return new D(); }
@Bean public E e() { return new E(c(), f()); }
@Bean public F f() { return new F(); }

Ну в чем-то вы правы. Если не использовать @Component и не использовать XML-конфиги, то в Спринге нет способа сказать "вот этот класс - компонент - просто сам найди, какой его конструктор использовать (если он там один) и сам создай его и все что надо по пути".

При использовании java-конфигураций нужно самому все бины создавать через new. Почти как в ручном DI. Но это делается более-менее декларативно и порядок, в котором создавать бины (дерево зависимостей) DI-контейнер строит все таки сам. Вы нигде вручную не вызываете эти методы-фабрики-бинов (вызов методов в вашем примере на самом деле не вызывает эти методы - там прокси).

А затем везде, где нужен какой-то бин (даже в этой или другой java-конфигурации) он уже просто инжектится, без привязки и какого-либо знания, где и как он был создан.

В приведенном вами конфиге вы инжектите бины через method-reference, возможно поэтому кажется, что бины что-то знают о том, как создаются используемые ими зависмости.

Но обычно в приложении гораздо больше одного класса-конфига. Одни конфиги инжектят в себя бины, создаваемые в совершенно других конфигах, которые возможно даже лежат в других модулях, и потом используют эти заинжектенные бины, чтобы создавать через new новые бины. Так что связанность все равно низкая.

Определение бина через new все так же ничего не знает о том, как были созданы используемые в конструкторе зависимости. Но появляется гибкость, какой именно конструктор использовать (если их большое 1-го), появляется возможность после new вызвать еще какой-нибудь метод (setSomething) и т.д. А для 3rd-party классов это еще важнее. Туда просто не получится навесить @Component или @PostConstruct.

Спасибо за развёрнутый ответ. А как именно можно в одном бине использовать бин из другого конфига? В эти фабричные методы можно аргументы добавлять? Или только в текущем классе-конфиге сделать поле с @Autowired и его потом использовать внутри методов?

и так и так можно

90% разрабов в спринге делают так:

@Service
public class MyService1 implements Service1 { ... }


@Service
public class MyService2 implements Service2 {
private final Service1 service1;

public MyService2(Service1 service1) {
this.service1 = service1;
}

А запускается всё через @SpringBootApplication (у которого внутри прописан @ComponentScan).

Ору

Можно передавать как аргумент в @Bean метод

@Service
public class MyService1 implements Service1 { ... }


@Service
public class MyService2 implements Service2 {
private final Service1 service1;

public MyService2(Service1 service1) {
this.service1 = service1;
}

Большинство заместо конструктора пишут @RequiredArgsConstructor на класс)

как?

Хола!

Мне нужно сопоставить значения двух листов

К примеру в 1 листе 10 слов
Во втором листе 5 слов
Мне надо сделать так, чтобы слова ставились 1 : 1
Даже если слова закончились у 1 листа, то надо чтобы ставился null : 6
и так далее. Тоже самое со вторым листом.
Как это сделать не получая NPE?

Мне бы хотелось узнать если ли такое решение через стримы?

Кто-то знает как парсить даты в RequestBody в  @MessageMapping ?
Так как в @RequestMapping не хочет работать там

Попробуй вот так
@JsonFormat(pattern = "dd-MM-yyyy HH:mm")
val date: Date

Работает, спасибо

То, что бин спринга отображается в плагине идеи еще не значит, что он существует в контексте спринга в рантайме. При вызове транзакционного метода спринг смотрит в атрибуты транзакции и ищет менеджер транзакции либо по qualifier, либо по transactionManagerBeanName, либо пытается взять дефолтовый. (можно глянуть org.springframework.transaction.interceptor.TransactionAspectSupport#determineTransactionManager) Судя по тому, что квалифаер не указан, сработало второе условие и спринг пытается вытащить менеджер по transactionManagerBeanName , который по умолчанию называется "transactionManager", соответственно бина такого нет. Скорее всего у вас где-то определен кастомный менеджер, а дефолтовый не создается из-за ConditionalOnMissingBean

есть @Controller класс, это норм если он будет имплиментить какой-то мой интерфейс?