복붙노트

[SPRING] Spring BeanPostProcessor는 정확히 어떻게 작동합니까?

SPRING

Spring BeanPostProcessor는 정확히 어떻게 작동합니까?

Spring Core 인증을 위해 공부하고 있습니다. Spring에서 bean 수명주기를 처리하는 방법과 특히 bean postprocessor에 대한 몇 가지 의문점이 있습니다.

그래서 나는이 스키마를 가지고있다.

그것이 의미하는 바가 꽤 분명합니다.

다음 단계는 Bean 정의로드 단계에서 수행됩니다.

그런 다음 콩 생성 단계에서 다음 단계가 수행됩니다.

좋아, 이것은 나에게 꽤 명확하다. 그리고 나는 또한 두 종류의 빈 포스트 프로세서가 있다는 것을 알고있다 :

그리고이 슬라이드를 게시합니다.

따라서 이니셜 라이저는 @PostContruct 어노테이션으로 주석을 붙인 메소드이며, setter 메소드 바로 다음 (의존성 삽입 이후)에 자동으로 호출되는 메소드 인 Bean 포스트 프로세서가 무엇인지 명확히 알고 있습니다. 이전 초기화와 같이 캐시를 채우는 것과 같은 초기화 배치를 수행하십시오.

하지만 다른 콩 포스트 프로세서를 정확히 나타내는 것은 무엇입니까? 이 단계가 초기화 단계 전후에 수행된다고 할 때 우리는 무엇을 의미합니까?

그래서 콩이 인스턴스화되고 그 의존성이 주입되므로 초기화 단계가 완료됩니다 (@PostContruct 주석 메소드의 실행에 의해). Bean Post Processor가 초기화 단계 전에 사용된다고 말하는 것은 무엇을 의미합니까? 그것은 @PostContruct 주석이 달린 메소드 실행 이전에 일어난다는 것을 의미합니까? 의존성 주입 (setter 메소드가 호출되기 전에)이 일어나기 전에 일어날 수 있다는 것을 의미합니까?

그리고 그것이 초기화 단계 후에 수행된다고 정확히 말할 때 무엇을 의미합니까? 즉, @PostContruct에 주석이 달린 메소드가 실행 된 후에 발생합니다.

@PostContruct 주석이 달린 메소드가 필요한 이유를 쉽게 이해할 수 있지만 다른 종류의 빈 포스트 프로세서에 대한 전형적인 예를 생각할 수 없습니다. 사용되는 전형적인 예를 보여줄 수 있습니까?

해결법

  1. ==============================

    1.Spring doc은 BeanPostProcessor를 사용하여 Bean 커스터마이징에서 BPP를 설명한다. BPP 빈은 다른 빈보다 먼저 생성되어 새로 생성 된 빈과 상호 작용하는 특별한 종류의 빈입니다. 이 구조를 사용하면 Spring은 직접 BeanPostProcessor를 구현하여 라이프 사이클 동작에 연결하고 사용자 정의 할 수있는 방법을 제공합니다.

    Spring doc은 BeanPostProcessor를 사용하여 Bean 커스터마이징에서 BPP를 설명한다. BPP 빈은 다른 빈보다 먼저 생성되어 새로 생성 된 빈과 상호 작용하는 특별한 종류의 빈입니다. 이 구조를 사용하면 Spring은 직접 BeanPostProcessor를 구현하여 라이프 사이클 동작에 연결하고 사용자 정의 할 수있는 방법을 제공합니다.

    BPP와 같은 사용자 지정 BPP

    public class CustomBeanPostProcessor implements BeanPostProcessor {
    
        public CustomBeanPostProcessor() {
            System.out.println("0. Spring calls constructor");
        }
    
        @Override
        public Object postProcessBeforeInitialization(Object bean, String beanName)
                throws BeansException {
            System.out.println(bean.getClass() + "  " + beanName);
            return bean;
        }
    
        @Override
        public Object postProcessAfterInitialization(Object bean, String beanName)
                throws BeansException {
            System.out.println(bean.getClass() + "  " + beanName);
            return bean;
        }
    }
    

    호출되어 모든 생성 된 빈에 대한 클래스 및 빈 이름을 출력합니다.

    메소드가 빈의 라이프 사이클에 맞는 방법을 이해하고 메소드가 정확히 호출 될 때 문서를 확인하십시오.

    중요한 비트는 또한

    @PostConstruct와 관련해서는이 주석이 postProcessAfterInitialization 메소드를 선언하는 편리한 방법이며, Spring은 registerCommonAnnotationBeanPostProcessor를 사용하거나 Bean 설정 파일에서 를 지정할 때이를 인식하게된다. @PostConstruct 메서드가 다른 postProcessAfterInitialization 앞이나 뒤에 실행되는지 여부는 order 속성에 따라 다릅니다.

  2. ==============================

    2.빈 포스트 프로세서의 전형적인 예는 원래 빈을 프록시 인스턴스에 래핑하려는 경우입니다. @Transactional 주석을 사용할 때.

    빈 포스트 프로세서의 전형적인 예는 원래 빈을 프록시 인스턴스에 래핑하려는 경우입니다. @Transactional 주석을 사용할 때.

    빈 포스트 프로세서는 빈의 원래 인스턴스를 넘겨 주며, 타겟의 메소드를 호출 할 수 있지만, 애플리케이션 컨텍스트에 바인드되어야하는 실제 빈 인스턴스를 리턴한다. 그것을 원하는 대상. 이것이 유용한 경우의 전형적인 시나리오는 빈 포스트 프로세서가 프록시 인스턴스에서 타겟을 래핑하는 경우입니다. 응용 프로그램 컨텍스트에서 바인드 된 bean의 모든 호출은 프록시를 통과 할 것이고, 그런 다음 프록시는 대상 bean에서 호출하기 전이나 후에 마술을 수행하게됩니다. AOP 또는 트랜잭션 관리.

  3. ==============================

    3.차이점은 BeanPostProcessor가 컨텍스트 초기화에 연결되어 정의 된 모든 bean에 대해 postProcessBeforeInitialization 및 postProcessAfterInitialization을 호출한다는 것입니다.

    차이점은 BeanPostProcessor가 컨텍스트 초기화에 연결되어 정의 된 모든 bean에 대해 postProcessBeforeInitialization 및 postProcessAfterInitialization을 호출한다는 것입니다.

    그러나 @PostConstruct는 생성자 또는 설정 메소드 후에 빈 생성을 사용자 정의하려는 특정 클래스에만 사용됩니다.

  4. from https://stackoverflow.com/questions/29743320/how-exactly-does-the-spring-beanpostprocessor-work by cc-by-sa and MIT license