이 기사는 주로 인스턴스를 초기화하기 전후에 스프링 컨테이너에서 제공하는 일부 콜백 방법과 확장 가능한 포인트를 요약합니다. 이러한 방법 및 확장 지점을 사용하면 스프링 초기화 인스턴스 전후에 일부 특수 논리 처리를 수행 할 수 있습니다.
다음은 주로 소개됩니다.
클래스 수준의 수명주기 초기화 콜백 메서
컨테이너 수준 확장 BeanPostProcessor 인터페이스 및 BeanFactoryPostProcessor 인터페이스
1. 클래스 수준의 수명주기 콜백
1.1init-method
참조 : SpringBeanxSdinit-Method
Init-Method는 스프링 구성 파일에서 Bean을 선언 할 때 구성 항목입니다. 초기 메드 구성 항목의 값은 클래스에서 매개 변수가없는 메소드이지만 예외를 던질 수 있습니다. 이 방법은 스프링 컨테이너가 개체를 인스턴스화하고 속성 값을 설정 한 후에 호출됩니다.
init-method에서 구현할 수있는 기능은 초기화 비 인터페이스 및 우편 제조 주석과 일치합니다.
스프링 구성 파일 및 테스트 클래스는 다음과 같습니다.
<bean id = "initmethodbeanservice"init-method = "init"> <property name = "f2"value = "2"/> </bean>
테스트 클래스는 다음과 같습니다.
Public Class Initmethodbeanservice {private static integer f1; private integer f2; static {f1 = 1; system.out.println ( "initmethodbeanservice static block execute ...");} public initmethodbeanservice () {system.out.println ( "initmethodbeanservice schetured schetured extruct exervice schetured indoid init () {system.out.println ( "initmethodbeanservice init 메소드 execute ...");} public integer getf2 () {return f2;} public void setf2 (integer f2) {this.f2 = f2; system.out.println ( "initmethodbeanservice setf2 방법 ...실행 결과는 다음과 같이 인쇄됩니다.
initmethodbeanservice 정적 블록 실행 ... initmethodbeanservice construct method execute ... initmethodbeanservice setf2 method execute ... initmethodbeanservice init method execute ... 테스트 메소드 실행 ...
1.2InitializingBean 인터페이스
참조 : 스프링 공식 문서 콩 주파수-리프 사이클 초기화 비안
초기화 된 Bean 인터페이스는 Spring 컨테이너가 객체를 인스턴스화하고 속성 값을 설정 한 후 호출되는 Method AfterProperTiesset을 선언합니다. 이는 초기 메드 위에 구현 된 기능과 일치하므로 Spring은 초기화 비 인터페이스를 사용하지 않는 것이 좋습니다.
예제는 비교적 간단하지 않고 나열되지 않습니다
1.3postconstruct 주석
번역 : 봄 공식 문서 Beans-Postcructs and Predestroy-Nantations
@PostConstruct 주석은이 시작 및 초기화 비면 인터페이스의 구현과 일치하는 수명주기 콜백 메소드입니다.
@PostConstructPublic void postconstruct () {System.out.println ( "postconstructService execute ...");}위의 세 가지 수명주기 콜백 메소드이 시작, 초기화 비 인터페이스, @postconstruct 주석을 요약하십시오.
1. 모두 단일 클래스에 대한 인스턴스화 및 후 처리됩니다
2. 실행 시간은 클래스 인스턴스화 후에 호출되며 멤버 변수가 주입됩니다.
3. init-method의 경우 스프링 구성 파일의 Beans 요소에서 기본 초기화 메소드를 구성 할 수도 있고 구성 항목은 기본 인트 메드입니다.
4. 위의 세 가지 메소드에서 구성된 초기화 메소드가 다른 경우 실행 순서는 다음과 같습니다. @PostConstruct Annotation 메소드> 초기화 AfterProperTiesset> init-method 메소드; 세 가지 메소드로 구성된 메소드가 동일하면 방법은 한 번만 실행됩니다 (참조 : 스프링 공식 문서 콩나무 윤리주기 경쟁-효과)
5. 초기 콜백 메소드가 있으며 콜백 메소드가 파괴됩니다. @PostConstruct 주석 메소드> 초기화 비안의 후 프로 테티 세트> init-method 메소드 @PredEstroy 주석에 해당합니다.
2. 컨테이너 레벨 확장
번역 : 스프링 공식 문서 3.8containerexextensionpoints
일반적으로 개발자는 SpringIOC 컨테이너를 확장하기 위해 ApplicationContext의 서브 클래스를 사용자 정의 할 필요가 없습니다. Springioc 컨테이너는 일부 노출 된 인터페이스를 통해 Springioc 컨테이너의 확장을 달성 할 수 있습니다.
2.1BeanPostProcessor 인터페이스
2.1.1Bean 사후 프로세서 및 후 프로세서 체인의 초기화
BeanPostProcessor 인터페이스는 인스턴스를 초기화 한 후 일부 논리적 처리에 사용되며 컨테이너의 모든 인스턴스에 대해 처리 된 후 일부 논리 처리에 사용되는 2 개의 컨테이너 레벨 콜백 방법 및 후 프로세스 후 손실 화를 정의합니다. BeanPostProcessor 인터페이스를 구현하는 클래스를 Bean 인스턴스 초기화 후 프로세서라고합니다.
다중 인스턴스 초기화 후 프로세서가 SpringIOC 컨테이너에 통합되는 경우 이러한 후 처리기의 세트를 BEAN 인스턴스 초기화 후 처리기 체인이라고합니다.
사후 프로세스의 전신 소화 방법은 클래스 인스턴스화 및 멤버 변수 주입이 완료된 후 및 초기화 방법 (예 : 초기화 AfterProperTiesset 메서드) 전에 실행됩니다.
후 프로세스 감독관은 클래스 인스턴스화 후에 실행되며 멤버 변수 주입이 완료되고 초기화 방법 (예 : 초기화 AfterProperTiesset 메서드)이 실행됩니다.
요약 :
1. 인스턴스 초기화 사후 처리기는 주로 인스턴스의 일부 프록시 작업에 사용됩니다. Spring에서 AOP를 사용하는 일부 기능도 후 처리기를 통해 구현됩니다.
2. 인스턴스 초기화 사후 처리기 체인은 다수의 후 처리기이며 실행 순서에 문제가 있습니다. 정렬 된 인터페이스를 구현하여 사후 처리의 실행 순서를 지정할 수 있습니다. 순서 대기면은 getOrder 메소드를 선언합니다. 방법의 반환 값이 작을수록 사후 처리의 우선 순위가 높아지고 이전 실행이 더 높습니다.
3. BeanPostProcessor 인터페이스를 구현하여 포스트 프로세서를 초기화 할 때 순서 대면 인터페이스를 구현하고 우선 순위를 지정하는 것이 좋습니다.
4.이 후 프로세서의 범위는 현재 Springioc 컨테이너, 즉 후 처리기가 선언 된 Springioc 컨테이너입니다. 계층 구조가있는 SpringIOC 컨테이너의 경우, 인스턴스 초기화 후 프로세서 체인은 두 컨테이너가 동일한 계층에 있더라도 다른 컨테이너에 의해 초기화 된 인스턴스에 작용하지 않습니다.
5. 인스턴스 초기화 사후 처리기의 구현 클래스는 일반 스프링 관리 콩과 동일하게 선언되면됩니다. SpringIOC 컨테이너는 자동으로 감지하여 인스턴스 초기화 사후 프로세서 체인에 추가합니다.
6. 자동 감지와 비교하여 인스턴스 초기화 후 처리기를 인스턴스 초기화 후 프로세서 체인에 프로그래밍 적으로 추가하기 위해 구성 가능한 비안 작용의 AddBeanPostProcessor 메소드를 호출 할 수 있습니다. 이는 조건을 추가 해야하는 시나리오에서 더 실용적입니다. 이 프로그래밍 접근법은 구현 된 차수 인터페이스에 의해 지정된 순서를 무시하지만, 사후 처리기의 초기화 전에 자동으로 감지되는 모든 인스턴스에서 작용합니다.
2.1.2 Bean 인스턴스 초기화 후 프로세서 및 AOP
BeanPostProcessor는 특수 인터페이스이며,이 인터페이스를 구현하는 클래스는 스프링 관리 콩의 경우 포스트 프로세서로 사용됩니다. 따라서 Spring Application 컨텍스트 시작의 특수 단계에서 BeanPostProcessor 인터페이스를 구현하는 모든 인스턴스가 직접 초기화되고 인스턴스에서 참조 된 클래스도 인스턴스화됩니다. 그런 다음 다른 정상 인스턴스에 적용 할 후 프로세서로서.
AOP의 자동 프록시는 인스턴스화 후 프로세서의 형태로 구현되므로 Bean 인스턴스는 후 처리기 체인 인스턴스를 초기화하거나 참조 된 인스턴스를 자동으로 파악할 수 없습니다. 그러므로이 예에서 얼굴을 직조하지 마십시오. (이 인스턴스의 경우 로그 메시지가 생성됩니다.
참고 : 인스턴스화 후 프로세서가 Autowiring 또는 @Resource의 형태로 다른 콩을 언급 할 때, 스프링 컨테이너는 유형 일치 의존성을 주입 할 때 비 지정 콩을 주입 할 수 있습니다 (예 : 인스턴스티브 포스트 프로세서 구현 클래스는 자원의 형태에 따라 콩에 의존하지 않으면 종속적 인 Bean의 이름을 세울 수 있습니다. 일치 유형의 형태로 주입되며, 현재로서는 비 지정 콩이 주입 될 수 있습니다). 또한 자동 프록시 또는 기타 인스턴스화 후 처리기 처리 방법이 실패 할 수 있습니다.
2.1.3 Bean 인스턴스 초기화 후 프로세서 예제
Public Class BeanPostProcessorService는 BeanPostProcessor {@override public Object PostProcessAfterinitialization (Object O, String S)을 Beansexception {System.out.println ( "BeanPostProcessorService execute ...")@retain object O) Postride ST의 O) BeanSexection {System.out.println ( "BeanPostProcessorService postprocessbeforeinitialization method execute ..."); return o;}}2.2BeanFactoryPostosor 인터페이스
2.2.1 BeanFactory 후 처리기
BeanFactoryProcessor 인터페이스를 구현하면 컨테이너가 관리하는 Bean의 구성 메타 데이터를 읽고 Bean이 인스턴스화되기 전에 변경할 수 있습니다. 이 콩을 콩 변형 후 프로세서라고합니다.
BeanFactoryPostProcessors와 BeanPostProcessor 인터페이스의 유사점과 차이점 :
유사성 :
모두 컨테이너 수준의 후 프로세서입니다
모두 여러 후 프로세서로 구성 할 수 있으며 순서 대면을 구현하여 실행 순서가 지정됩니다.
인터페이스로 선언 된 컨테이너에서 관리되는 콩에 대해 처리됩니다. 계층 구조가있는 컨테이너에서는 두 컨테이너가 같은 수준에 있더라도 다른 용기의 콩을 처리 할 수 없습니다.
그들 모두는 일반 콩과 같은 용기에만 선언되기 만하면됩니다. 컨테이너는 후 프로세서로 자동 감지 및 등록됩니다.
지연 초기화 속성 구성은 무시됩니다
차이점 :
BeanFactoryPostProcessors 인터페이스는 콩을 인스턴스화하기 전에 Bean의 구성 메타 데이터를 처리하며 BeanPostProcessor 인터페이스는 콩을 인스턴스화 한 후 콩의 인스턴스를 처리합니다 **
BeanFactoryPostProcessors 인터페이스는 BeanFactory.getBean () 메소드를 통해 Bean 인스턴스를 얻을 수 있으며, 이로 인해 Bean이 인스턴스화됩니다. BeanFactoryPostProcessors 후 프로세서가 모든 콩이 인스턴스화되기 전에 실행되기 때문에 BeanClory.getBean () 방법으로 인해 콩이 미리 인스턴스화되므로 컨테이너 표준의 수명주기가 깨지기 때문에 부정적인 영향을 미칠 수 있습니다 (예 : 사전에 콩이 인스턴스화 된 후 보호 조치의 처리를 무시할 수 있습니다).
2.2.2 스프링 내장 및 맞춤형 멍청한 사후 처리기
Spring에는 BeanFactory 후증기가 내장되어 있습니다 (예 : PropertyPlaceHolderConfigurer 및 PropertyOverRideConfigurer). 또한 BeanFactoryPostProcessor 인터페이스의 구현을 지원하고 BeanFactory 후 처리기를 사용자 정의합니다. Spring의 내장 후 프로세서 및 사용자 정의 후 처리기에 대해 이야기 해 봅시다.
PropertyPlaceHolderConfigurer
기본 XML 정의 파일의 수정으로 인한 위험을 피하기 위해 Spring은 구성 분리를 제공하고 속성 구성 파일로 변경 될 수있는 일부 변수를 구성하고 XML 정의 파일에서 자리 표시 자로 참조 할 수 있습니다. 이러한 방식으로 구성을 수정하려면 속성 구성 파일을 수정하면됩니다. PropertyPlaceHolderConfigurer는 자리 표시자를 감지하고 자리 표시자를 구성 속성 값으로 교체하는 데 사용됩니다. 예는 다음과 같습니다.
PropertyPlaceHolderConfigurer는 jdbc.properties 속성 구성 파일을 사용하여 DataSource Bean의 데이터베이스 관련 정보에 대한 속성 자리 표시기를 런타임시 해당 구성 값으로 바꿉니다.
XML 구성은 다음과 같습니다.
<ean> <property name = "locations"value = "classpath : com/foo/jdbc.properties"/> </bean> <bean id = "dataSource"destroy-method = "close"> <property name = "driverclassName"value = "$ {jdbc.driverClassName}"/>> <value = "url"$ {jdbc.uurl 이름 = "username"value = "$ {jdbc.username}"/> <속성 이름 = "password"value = "$ {jdbc.password}"/>속성 구성 파일 jdbc.properties는 다음과 같습니다.
jdbc.driverclassname = org.hsqldb.jdbcdriverjdbc.url = jdbc : hsqldb : hsql : // production : 9002jdbc.username = sajdbc.password = root
PropertyPlaceHolderConfigurer는 속성 구성 파일의 읽기를 지원할뿐만 아니라 시스템 속성 읽기를 지원합니다. SystemPropertiesMode 속성 값을 통해 읽기 우선 순위를 구성 할 수 있습니다. 다양한 값은 다음과 같이 설명됩니다.
0 : 시스템 속성을 읽지 마십시오
1 : 해당 자리 표시 자의 구성이 참조 속성 구성 파일에서 검색되지 않으면 시스템 속성을 읽습니다. 기본값은 1입니다
2 : 먼저 시스템 속성을 읽은 다음 참조 된 속성 구성 파일을 읽으십시오. 이 구성으로 인해 시스템 속성이 구성 파일을 덮어 쓸 수 있습니다.
PropertyOverRideConfigurer
PropertyOverRideConfigurer 클래스는 속성 구성 파일을 참조하여 컨테이너의 Bean에 값을 직접 할당 할 수 있습니다. Bean의 속성이 여러 PropertyOverRideConfigurer 클래스 인스턴스에 의해 할당되면 마지막 값은 이전 값을 대체합니다.
위의 DataSource Bean을 예를 들어 할당하십시오.
PropertyOverRideConfigurer 클래스는 다음과 같이 새로운 방법을 사용하여 속성 구성 파일을 참조합니다.
<컨텍스트 : 속성-오버 라이드 위치 = "classPath : Override.Properties"/>
Properties 속성 구성 파일의 이름 지정 규칙은 위의 것과 다릅니다 (위의 예에서는 속성 이름과 자리 표시자가 일관되도록해야합니다).
DataSource.driverClassName = com.mysql.jdbc.driverdatasource.url = jdbc : mysql : mydbdatasource.username = sadatasource.password = root
복합 속성의 할당을 지원하지만 할당 된 속성을 참조하는 객체가 비어 있지 않도록합니다 (예 : foo.fred.bob.sammy = 123).
맞춤형 콩 공장 후 프로세서
Custom Bean Factory Postprocessor는 Spring 컨테이너가 관리하는 Bean의 구성 메타 데이터 수정을 완료하기 위해 BeanFactoryPostProcessor 인터페이스를 구현합니다. 예 : 클래스 속성에 의해 주입 된 값을 수정하면 예는 다음과 같습니다.
사용자 클래스 사용자 비안을 정의합니다
공개 클래스 userBean {private String username; public string getUserName () {return username;} public void setusername (String username) {this.username = username;}}Spring XML 구성 파일은 사용자 클래스를 구성하고 value haha를 사용자 이름 속성 사용자 이름에 주입합니다.
<bean/> <bean id = "user"> <property name = "username"value = "haha"/> </bean>
아래는 사용자 정의 Bean Factory Postprocessor이며 속성 사용자 이름의 값을 Heihei로 수정하십시오.
Public Class BeanFactoryPostProcessorService는 BeanFactoryPostProcessor {@override public void postProcessBeanFactory (configurableBeListableBeanFactory BeanFactory) Beansexception {System.out.println ( "BeanCatoryPostorservice executue ..."); beandefinition bd = beanfactory.getBeanDefinition ( "사용자"); mutablepropertyvalues pv = bd.getPropertyValues (); if (pv.contains ( "username")) {pv.addpropertyvalue ( "username", "heihei"); }}}요약
위는이 기사에서 스프링 라이프 사이클 콜백 및 컨테이너 확장에 대한 자세한 설명입니다. 모든 사람에게 도움이되기를 바랍니다. 관심있는 친구들은이 사이트를 계속 참조 할 수 있습니다.
봄에 맞춤형 주석의 적용에 대한 간단한 토론
Spring의 IOC 코드 분석
SpringMVC 인터셉터 핸들러 인터셉터 사용 코드 예제
단점이 있으면 메시지를 남겨 두십시오. 이 사이트를 지원해 주신 친구들에게 감사드립니다!