Можно ли использовать @PostConstruct вместо @Bean/@Produces?

Я читал этот пост, когда я подумал о возможности замены любого @Bean (Spring DI) или @Produces (CDI) с простым @PostConstructor как в следующем примере CDI:

Заменить:

public class MyClassFactory {

    @Produces
    @RequestScoped
    public MyClass createMyClass() {
        MyClass myClass = new MyClass();
        myClass.setA(1);
        return myClass;
    }
}

public class MyClass {

    private int a;

    private void setA(int a) {
        this.a = a;
    }
}

С:

public class MyClass {

    @PostConstruct
    public void init() {
        this.setA(1);
    }

    private int a;

    private void setA(int a) {
        this.a = a;
    }
}

Это верно? Каковы различия между этими вариантами?

2 ответа

Решение

Нет, @PostConstruct определяет перехватчик для инициализации компонента. Он не может использоваться для определения экземпляра бина.

Я не считаю это неправильным вопросом.

Метод @PostConstruct вызывается после вызова конструктора по умолчанию и внедрения зависимости (если есть). Вы можете инициализировать переменные экземпляра bean-компонента с помощью аннотированного метода @PostConstruct. В этом случае различие между чередованием и использованием @PostConstruct и CDI состоит в том, что экземпляр, возвращаемый CDI, является контекстным, и, поскольку он является @RequestScoped, время жизни "созданного" компонента ограничивается одним HTTP-запросом. Новый экземпляр компонента будет создан после завершения существующего HTTP-запроса. В случае @PostConstruct, его компонент @Dependent scoped (по умолчанию) и его жизненный цикл будут "зависеть" от компонента, который его внедряет (используя CDI @Inject)

Другие вопросы по тегам