스프링 빈 주입 코드 분석

[muf]

https://tech.kakaopay.com/post/martin-dev-honey-tip-2/#summary

• ApplicationContext가 컨테이너가 된다고 했으니, 주요한 초기화 작업도 여기서 이루어진다고 유추

• ApplicationContext interface 코드 확인

  <!--
  * In addition to standard org.springframework.beans.factory.BeanFactory lifecycle capabilities
  * ApplicationContext implementations detect and invoke beans
    - ApplicationContextAware
    - ResourceLoaderAware
    - ApplicationEventPublisherAware
    - MessageSourceAware beans. 
  * See Also: 
    - ConfigurableApplicationContext
    - org.springframework.beans.factory.BeanFactory
    - org.springframework.core.io.ResourceLoader
  -->

• 구현체를 검색해보면 상당히 많다

  • 직접 확장하는 인터페이스 2개

    WebApplicationContext ConfigurableApplicationContext

  • 실 구현체는 너무 많으니, 어플리케이션 하나 구동해서 실제 사용하는 구현체를 잡아서 확인해보자
  • 그래서 우리 boot application은 무슨 context를 사용하는걸까?

• run(${applicaiton})을 실행

  • SpringApplication 생성
  • deduceFromClasspath를 통해 타입 결정 (로드된 클래스를 기반으로 분석하는 부분이 있음)
  • ApplicationContextInitializer, ApplicationListener 클래스 찾아서 set
    • ApplicationContextInitializer

      

    • ApplicationListener

      

  • run
  • SpringApplicationRunListener 클래스 찾아온 후에 starting() 으로 시작시킴

    

  • env 값 로드

    profile, property, logger 등 설정 로드

  • createApplicationContext()로 컨텍스트 생성

    현재 구동 앱은 AnnotationConfigServletWebServerApplicationContext를 사용 (부트에서 제공) AnnotationConfigServletWebServerApplicationContext() 기본 생성자 호출

  • prepareContext
    • env 설정
    • postProcessApplicationContext

      setConversionService 행위가 이루어졌음 (내부적으로 제공하는 컨버팅 관련 무언가를 셋팅해주는 느낌)

    • applyInitializers

      각종 초기화 관련 클래스들을 등록 필요한것들을 부트에서 적절하게 넣어주는 과정들. 이것이 바로 bootstrap!

      

    • listeners.contextPrepared(context)
    • beanFactory 생성

      context.getBeanFactory() DefaultListableBeanFactory 지금은 ConfigurableListableBeanFactory 구현체가 이거 하나이긴함

    • 싱글톤 "springApplicationArguments" 등록

      beanFactory.registerSingleton("springApplicationArguments", applicationArguments) DefaultApplicationArguments 가 등록되었음

    • load

      getBeanDefinitionRegistry 이건 어플리케이션만 등록 하는것 같긴 하네

    • listeners.contextLoaded(context)

      리스너들에게 이벤트 핸들링 할 수 있게 트리거 발생하는 요소로 이해

  • 여기까지 왔을때 빈 목록을 보면 BO는 하나도 없고, internalAutoWiredAnnotationProcessor, internalConfigurationAnnotationProcessor 요런거 보임
  • refreshContext !!!!!!!

    이걸 실행하면 나머지가 다 목록으로 보이기 시작

  • afterRefresh

    dummy 코드

  • listeners.started(context)
  • callRunners(context, applicationArguments)
  • listeners.running(context);
  • return context

    왜 return 하지? 이게 필요한 경우가 있나? 어디 저장해두고 접근하고 싶을때? 따로 공용 저장 공간이 있나 한건 아닌것 같기도 (등록하는 코드가 없으니)

[muf]

상세 분석

SpringApplication::refresh(ConfigurableApplicationContext applicationContext) 코드 분석 빈은 그냥 이름 기반으로 오브젝트를 만드는거고, 등록은 싱글톤임

• prepareBeanFactory
• environment 등 일부 빈 싱글톤 등록 싱글톤 registry가 있고, 여기에 저장됨 DefaultSingletonBeanRegistry beanFactory.getSingletonNames() 나머지도 bean 타입별로 registry가 있으려나.?
• invokeBeanFactoryPostProcessors bean names 목록에 싱글톤 후보 빈 이름 추가 싱글톤 등록되 되는 것으로 보임
• registerBeanPostProcessors 이건 그냥 aop 스러운 그런거 같은데..?
• bean의 post processor 항목들

invokeBeanFactoryPostProcessors

• // Parse each @Configuration class

  processConfigurationClass ConfigurationClassParser::doProcessConfigurationClass !!! 여기다

• processConfigurationClass > doProcessConfigurationClass (이 do while에서 nested 되어있는 설정들을 꺼내서 빈들을 찾아내는 과정으로 보임)
• 이 과정을 통해 configurationClasses에 하나 씩 추가됨

  configurationClasses

---

• [ ] 아 근데 이게 등록은 하는데 실제 resolve 과정에서 뭘 주입해주느냐는 다른 문제구나..?

[muf]

기타 메모

• [ ] SpringBootConfiguration 이거 어노테이션 붙이면 실제 처리하는 aspect 클래스는 어떻게 찾지?
• [ ] Lifecycle 개념
• [ ] Spring Listener ?
• [ ] getSpringFactoriesInstances
• [ ] Context listeners에 대해서
• [ ] setAllowBeanDefinitionOverriding ??
• [ ] LazyInitializationBeanFactoryPostProcessor ??
• [ ] addConversionService ??
• [ ] ConversionService ??
• [ ] ApplicationConversionService ??
• [ ] refresh는 뭘 하는 행위인가 ??
• [ ] 빈 / 싱글톤 등록된거 목록 볼 수 있나?

  beanFactory.getBeanNamesIterator()