Можно ли использовать @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)