본문 바로가기

SpringFramework Core - I. IoC 컨테이너

 (101)
1.8.1. BeanPostProcessor로 Bean 커스터마이징하기 BeanPostProcessor 인터페이스는 나만의 인스턴스화 로직, 의존성 로직 등을 제공하게 해주는, 또는 컨테이너의 기본값들을 오버라이드하게 해주는 콜백 메소드를 정의한다. 만약 스프링 컨테이너가 인스턴스화, 설정, bean 초기화를 마친 후에 커스텀한 로직을 실행하게하고 싶다면, 하나 이상의 커스텀한 BeanPostProcessor에 플러그인하면 된다. 여러 개의 BeanPostProcessor 인스턴스를 설정할 수 있다. 그리고 이 BeanPostProcessor들이 설정된 order 프로퍼티에 따라 실행되도록 명령을 제어할 수 있다. 이 프로퍼티는 오직 BeanPostProcessor가 Ordered 인터페이스를 구현했을 때에만 세팅할 수 있다. 만약 자신만의 BeanPostProcessor를..
1.8. 컨테이너의 확장가능한 사항들 일반적으로, 애플리케이션 개발자는 ApplicationContext의 구현 클래스들을 상속할 필요가 없다. 대신에 스프링 IoC 컨테이너는 인터페이스들의 특별한 결합에 플러그인함으로써 확장될 수 있다. 다음 몇 파트는 이 결합 인터페이스에 대해 설명한다.
1.7. Bean 정의 상속 Bean 정의는 많은 설정 정보를 포함할 수 있다. 생성자 매개변수, 프로퍼티 값들, 컨테이너 정보, 초기화 메서드, 정적 팩토리 메소드 이름 등등이 포함된다. 자식 bean 정의는 부모 정의로부터 설정 데이터를 상속받는다. 자식 정의는 몇몇 값들을 오버라이드할 수 있으며 다른 필요한 것들을 더할 수도 있다. 부모와 자식 bean 정의를 사용하는 것은 많은 타이핑을 줄여준다. 이것이 효과적으로 템플릿화하는 방법인 것이다. 만약 프로그램적으로 ApplicationContext를 가지고 작업을 한다면, 자식 bean 정의들은 ChildBeanDefinition 클래스로 표현된다. 대부분의 다른 사용자들은 이 단계에서 자식 bean들로 작업하지 않는다. 대신에 그들은 ClassPathXmlApplication..
1.6.3. 다른 Aware 인터페이스들 ApplicationContextAware과 BeanNameAware와 더불어, 스프링은 bean들이 컨테이너를 가리킬 수 있도록 하는 넓은 범위의 Aware 콜백 인터페이스를 제공한다. 일반적인 규칙으로써, 이름은 의존성 타입을 가리킨다. 다음 표는 가장 중요한 Aware 인터페이스들을 요약한다. 이름 주입된 의존성 다음에서 설명... ApplicationContextAware ApplicationContext ApplicationContextAware과 BeanNameAware ApplicationEventPublisherAware ApplicationContext를 감싸고 있는 이벤트 publisher ApplicationContext의 추가 기능들 BeanClassLoaderAware 클래스로더가..
1.6.2. ApplicationContextAware과 BeanNameAware ApplicationContext가 org.springframework.context.ApplicationContextAware 인터페이스를 구현한 객체의 인스턴스를 만들면, 그 인스턴스는 ApplicationContext를 참조로써 제공받는다. 다음 예시는 ApplicationContextAware 인터페이스의 정의를 보여준다. public interface ApplicationContextAware { void setApplicationContext(ApplicationContext applicationContext) throws BeansException; } 그래서 bean들은 프로그램적으로 그들 스스로를 만들어낸 ApplicationContext를 조작할 수 있게 된다. ApplicationCo..
1.6.1.6. 웹 앱이 아닐 때 스프링 IoC 컨테이너를 Gracefully하게 Shutting Down 하기 이 부분은 웹앱이 아닌 곳에서만 적용된다. 스프링의 웹 기반 ApplicationContext 구현체는 이미 관련된 웹앱이 shut down할 때 스프링 IoC 컨테이너를 gracefully하게 shut down시키는 코드를 가지고 있다. 만약 웹앱 환경이 아닌 곳에서 스프링의 IoC 컨테이너를 사용하고 있다면(예를 들어, rich client 데스크탑 환경) shutdown hook을 JVM에 등록하라. 그렇게 하면 graceful한 shutdown을 보장하며 싱글턴 bean들을 소멸시키는 관련 메소드를 호출하여 모든 리소스를 release하게 해줄 것이다. 여전히 이러한 소멸 콜백들은 정확하게 설정하고 실행해야만 한다. shutdown hook을 등록하기 위해서는, ConfigurableApplica..
1.6.1.5. Startup과 Shutdown 콜백 Lifecycle 인터페이스는 스스로의 라이프사이클 요구사항을 가진 객체들을 위한 본질적인 메소드를 정의한다 (몇몇 백그라운드 프로세스를 시작시키고 정지시키는 등). public interface Lifecycle { void start(); void stop(); boolean isRunning(); } 스프링의 관리를 받는 모든 객체는 Lifecycle 인터페이스를 구현하고 있을 것이다. ApplicationContext가 시작과 정지 신호를 받으면 해당 context 내에 정의된 모든 Lifecycle 구현체에 그 신호를 전달한다. 다음에서 보여주는 LifecycleProcessor에게 위임함으로써 그 일을 해낸다. public interface LifecycleProcessor extends Li..
6.1.4. 라이프사이클 메커니즘들 결합시키기 원문: https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/core.html#beans-factory-lifecycle-combined-effects 스프링 2.5에서는 bean의 라이프사이클 행동을 제어하기 위한 세 가지 옵션이 있다. InitializingBean과 DisposableBean 콜백 인터페이스 커스텀한 init()과 destroy() 메소드 @PostConstruct와 @PreDestroy 어노테이션. 이 메커니즘들을 주어진 bean을 컨트롤하기 위해 결합시킬 수 있다. ※ 만약 여러 라이프사이클 메커니즘이 설정되어 있고 각각의 메커니즘이 서로 다른 이름으로 설정되어 있다면, 각각의 설정된 메소드..

티스토리툴바