본문 바로가기

전체 글

 (214)
9.2. @Autowired 사용하기 원문: https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/core.html#beans-autowired-annotation ※ JSR-330의 @Inject 어노테이션은 이번 장의 예시들에 쓰인 스프링 @Autowired 어노테이션들을 대체할 수 있다. 자세한 내용은 여기를 참고하라. @Autowired 어노테이션은 다음 예시와 같이 생성자에 적용할 수 있다. public class MovieRecommender { private final CustomerPreferenceDao customerPreferenceDao; @Autowired public MovieRecommender(CustomerPreferenc..
9.1 @Required 원문: https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/core.html#beans-required-annotation public class SimpleMovieLister { private MovieFinder movieFinder; @Required public void setMovieFinder(MovieFinder movieFinder){ this.movieFinder = movieFinder; } // ... } 이 어노테이션은, bean의 해당 프로퍼티가 설정이 이뤄지는 동안에 채워져야 한다는 것을 의미한다. bean 정의의 명확한 프로퍼티 값을 통해 채워지거나, autowiring을 통해서 채워지..
9. 어노테이션 기반의 컨테이너 설정 스프링 설정에 '어노테이션'이 'XML'보다 나은가? 어노테이션 기반의 설정을 소개할 때는, 과연 이 접근이 XML보다 나은가하는 질문을 하게된다. 결론부터 말하자면, '때에 따라 다르다'이다. 좀 더 길게 말하자면, 각 방법은 나름대로의 장단점을 가지고 있고 개발자가 더 적합한 전략을 택하는 것에 달려있다고 할 수 있다. 어노테이션들은 정의되는 방식 덕분에 선언 속에서 많은 맥락을 제공할 수 있다. 이는 더 짧고 간결한 설정을 가능하게 해준다. 그러나 XML은 소스코드의 변경없이, 재컴파일없이 컴포넌트들을 wiring up하는 것에 뛰어나다. 몇몇 개발자는 소스와 밀접하게 wiring하는 것을 선호하는 반면에, 다른 개발자는 어노테이션이 붙은 클래스는 더 이상 POJO가 아니라고 주장한다. 또한 어노테..
1.8.3. FactoryBean으로 인스턴스화 로직 커스터마이징하기 팩토리인 객체들을 위해 org.springframework.beans.factory.FactoryBean 인터페이스를 구현할 수 있다. FactoryBean 인터페이스는 스프링 IoC 컨테이너의 인스턴스화 로직에 플러그인할 수 있는 지점을 제공한다. 만약 자바로는 더 간단하게 표현할 수 있지만 장황한 XML로 쓰여진 복잡한 초기화 코드들을 가지고 있다면, FactoryBean을 생성하고 그 클래스 안에서 복잡한 초기화들을 작성하여, 컨테이너로 플러그인시키면 된다. FactoryBean 인터페이스는 세 가지 메소드를 제공한다. Object getObject(): 해당 팩토리가 생성하는 객체의 인스턴스를 반환한다. 인스턴스는 해당 팩토리가 싱글턴을 반환하는지 프로토타입을 반환하는지에 따라 공유될 수도 있다...
1.8.2.2. 예시: PropertyOverrideConfigurer 또다른 bean 팩토리 후처리자인 PropertyOverrideConfigurer은 PropertySourcesPlaceholderConfigurer와 유사하다. 하지만 후자와 달리, bean 프로퍼티들을 위한 기본적인 정의가 기본 값들을 갖거나 아무 값을 가지지 않을 수도 있다. 만약 Properties 파일을 오버라이딩하는 것이 특정한 bean 프로퍼티로의 진입점을 갖지 않는다면, 기본적인 context 정의가 사용될 것이다. bean 정의는 오버라이드되도록 알려져 있지 않다는 점의 주의하라. 그래서 XML 정의 파일에서 오버라이드 설정자가 사용된다는 것이 즉시 명백해지는 것은 아니다. 같은 bean 프로퍼티에 대해 여러 PropertyOverrideConfigurer 인스턴스들이 서로 다른 값을 정..
1.8.2.1. 예시: 클래스명의 대체자 PropertySourcesPlaceholderConfigurer PropertySourcesPlaceholderConfigurer를 통해, 표준적인 자바 Properties를 사용함으로써 서로 다른 파일에 있는 bean 정의들로부터 프로퍼티 값들을 표면화할 수 있다. 그렇게하면 복잡하지 않게, 또 메인 XML 정의나 컨테이너를 위한 파일들을 수정할 때 따르는 위험성 없이 데이터베이스 URL들이나 비밀번호와 같은 환경 프로퍼티 값들을 커스터마이즈할 수 있는 애플리케이션을 배포할 수 있게 된다. 다음 XML 기반의 설정 메타데이터를 참고하자. DataSource가 placeholder 값으로 정의되었다. 예시는 외부의 Properties 파일에 설정된 프로퍼티들을 보여준다. 런타임 시에 PropertySourcesPlaceholderConfigurer가 메타데이터에 적용..
1.8.2. BeanFactoryPostProcessor로 설정 메타데이터 커스터마이징하기 우리가 다음으로 살펴볼 확장 가능한 부분은 org.springframework.beans.factory.config.BeanFactoryPostProcessor이다. 이 인터페이스의 의미는 BeanPostProcessor와 유사하지만 한 가지 다른 점이 있다. BeanFactoryPostProcessor는 bean 설정 메타데이터에서 작동하는 점이다. 즉, 스프링 IoC 컨테이너는 BeanFactoryPostProcessor 인스턴스들 외에 다른 bean들을 초기화하기 전에 BeanFactoryPostProcessor가 설정 메타데이터를 읽고 잠재적으로 그것을 바꿀 수 있도록 한다. 여러 개의 BeanFactoryPostProcessor 인스턴스를 설정할 수 있다. 그리고 order 프로퍼티를 세팅함으로..
1.8.1.2. 예시: RequiredAnnotationBeanPostProcessor 콜백 인터페이스들이나 커스텀 BeanPostProcessor 구현체를 통해 어노테이션을 쓰는 것은 스프링 IoC 컨테이너를 확장하는 일반적인 방법들이다. 예시는 BeanPostProcessor의 구현체인 스프링의 RequiredAnnotationBeanPostProcessor이다. 이것은 스프링 distribution을 담고 있다. 또한 어노테이션이 표시된 bean들의 자바빈 프로퍼티에 실제로 값이 주입되도록 보장한다.

티스토리툴바