Spring 5 State Based Bean Injection - возможно?

Question

Я пытаюсь найти некоторый «контроллер» (не @Controller) в Spring 5.0, который отвечает за решение, какой экземпляр реализации внедрить в Spring. Я хочу предоставить свою собственную реализацию этого контроллера (или расширить его), чтобы я мог добавить свой собственный лог c для разрешения бина на основе состояния.

Например, для некоторого интерфейса Foo, с реализация FooImpl1 и FooImpl2, а также некоторое состояние Baz.

Затем, когда Baz = 1, я хочу войти в свой собственный лог c, чтобы принять решение предоставить FooImpl1 вместо FooImpl2 для требуемого внедрения реализации Foo.

Spring делает это сегодня, логика c выглядит следующим образом:

• Учитывая необходимость внедрения класса X, найдите его реализации
• Если только один из X найдено, используйте это
• Если найдено более одного X, используйте Primary
• Если найдено более одного X и нет Primary, найдите Qualifier
• Если более чем один X, если он найден, и нет Primary и не определителя, попытайтесь сопоставить X со свойством или параметром X по имени (ie: не вводить Y, если параметром или свойством является x, а не y).

Что-то, что я хочу сделать, это в какой-то момент в логике c выше вызвать мою собственную неоднозначность / разрешение требуемой реализации для внедрения, основываясь на моих собственных логиках c и состоянии.

Итак, прежде чем я go и копаюсь в Spring, чтобы найти, где реализована эта логика c, я надеюсь обнаружить, что она реализована в каком-то контроллере / сервисе, который я могу расширить, лучше всего, если это будет поддержано некоторая конфигурация ...

Answer 1

Вы можете реализовать свою собственную @ Конфигурацию , которая возвращает Spring @ Bean :

@Configuration
public class Config {
    private final Baz baz;

    @Autowired
    Config(Baz baz) {
        this.baz = baz
    }

    @Bean
    public Foo getFoo() {
        switch (baz) {
            case 1:
                return new FooImpl1();
            default:
                return new FooImpl2();
        }    
    }
}

Пожалуйста, прочтите также параграф о Полная @Configuration vs «облегченный» режим @Bean? . В последнем абзаце говорится, что:

В обычном сценарии ios методы @Bean должны объявляться в классах @Configuration, гарантируя, что всегда используется «полный» режим и поэтому ссылки на перекрестные методы получить перенаправление на управление жизненным циклом контейнера. Это предотвращает случайный вызов одного и того же метода @Bean посредством обычного вызова Java, что помогает уменьшить тонкие ошибки, которые трудно обнаружить при работе в «облегченном» режиме.

Answer 2

Кажется, я ищу интерфейсы BeanFactory и, скорее всего, ConfigurableBeanFactory. Есть еще кое-что, чтобы работать вне курса, но это определенно правильное направление.

Для тех, кому сразу интересно, о чем я говорю ... см. https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/config/ConfigurableBeanFactory.html