JArchive 프로그래밍 일기

목표

1. 빈 생명주기 콜백 시작

2. 인터페이스 InitializingBean, DisposableBean (이번 포스팅)

3. 빈 등록 초기화, 소멸 메서드 

4. 애노테이션 @PostConstruct, @PreDestroy

2.  인터페이스 InitializingBean, DisposableBean 

1) 초기화 콜백: InitializingBean 인터페이스를 구현하자.

들어가보면, afterPropertiesSet() 메서드가 있다. 
"프로퍼티들의 세팅이 끝나면, 즉 의존관계 주입이 끝나면" 호출하는 메서드라는 뜻이다. 

의존관계 주입 후, 초기화 메서드 afterPropertiesSet() 가 호출된다. 

2) 소멸 전 콜백: DisposableBean 인터페이스를 구현하자.

destroy() 메서드는 빈이 소멸될 때 호출된다. 

두 개의 인터페이스를 구현한 후의 코드. 

이전 시간에 작성한 NetworkClient 테스트코드를 실행하고 출력을 확인하자.

스프링 컨테이너를 생성하고 빈을 조회하고, 컨테이너를 종료하는 내용이었다. 

객체 생성(생성자 호출)때는 당연히 url이 값이 없다. 

초기화 콜백  : 의존관계 주입 직후, connect() , call() 이 호출됬다. 

소멸전 콜백  : 컨테이너 종료(빈 소멸) 할 때 close를 출력하는 distroy()가 호출됬다. 

3) 초기화, 소멸 인터페이스의 단점

• 이 인터페이스는 스프링 전용 인터페이스다. 해당 코드가 스프링 전용 인터페이스에 의존한다.
• 초기화, 소멸 메서드의 이름을 변경할 수 없다.
• 내가 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다. 
• 인터페이스 방식은 2003년에 나온 방법이고, 지금은 더 나은 방법들이 있어서 거의 안 쓴다.

3. 빈 등록 초기화, 소멸 메서드 

설정 정보에 @Bean(initMethod = "메서드이름" , destroyMethod = "메서드이름") 으로 초기화, 소멸 메서드를 지정할 수 있다. 

1) 특징 

* 메서드 이름을 자유롭게 줄 수 있다.

* '설정 정보'를 사용하니까 외부 라이브러리에도 초기화, 소멸 메서드를 적용할 수 있다. 

2) 종료 메서드 추론 (inferred)

@Bean( destroyMethod = "메서드이름")에 특별한 기능이 있다. 

대부분 (외부)라이브러리의 종료 메서드 이름이 close, shutdown 임을 이용한 기능이다. 

@Bean 의 destroyMethod의 기본값이 (inferred) 로 등록되어 있다.

그래서 직접 스프링 빈으로 등록하면, close, shutdown 이름의 메서드를 자동으로 호출해준다. 

추론 기능을 사용하지 않으려면, @Bean( destroyMethod = "") 처럼 공백을 지정하면 된다.

4. [권장] 애노테이션 @PostConstruct, @PreDestroy 

내가 정의한 메서드에 애노테이션을 붙이는 방법이다. 편리하다. 

1) 특징 

* 최신 스프링에서 가장 권장하는 방법이다. 

* 패키지가 javax 로 시작하는데. 자바 표준이라는 의미다. 따라서 스프링이 아닌 다른 컨테이너에서도 잘 동작한다. 

* 유일한 단점은 외부 라이브러리에는 적용하지 못한다는 것이다. 

* 외부 라이브러리에는 @Bean(initMethod = "메서드이름") 방식을 쓰자. 

다음 시간에는 빈 스코프를 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편 

목표

1. 빈 생명주기 콜백 시작 (이번 포스팅)

2. 인터페이스 InitializingBean, DisposableBean

3. 빈 등록 초기화, 소멸 메서드 

4. 애노테이션 @PostConstruct, @PreDestroy

1.  빈 생명주기 콜백 시작

데이터베이스 커넥션 풀이나 네트워크 소켓처럼 tcp ip handshaking 등 연결을 위한 작업이 좀 많은 경우, 

미리 연결을 해두고 요청이 오면 연결을 바로 재활용 한다. 소켓도 미리 잡아놓아야 요청이 왔을 때 즉시 응답을 줄 수 있다. 

이런 건 애플리케이션 시작 시점에 필요한 연결을 미리 해둬야 한다.

DB 연결 종료와 소켓 닫는것도 애플리케이션 종료 직전에 해둬야 한다. 

이번 시간에는 스프링을 통해 객체의 초기화 작업과 종료 작업을 어떻게 진행하는지 예제로 알아보자. 

간단하게 외부 네트워크에 미리 연결하는 객체를 하나 생성한다고 가정해보자. 

실제 네트워크에 연결하는 건 아니고 문자만 출력한다. 

1) NetworkClient 클래스 

• 애플리케이션 시작 시점에 connect() 를 호출해서 연결을 맺어두어야 한다.
• 애플리케이션이 종료되면 disConnect() 을 호출해서 연결을 끊어야 한다. 

생성자에서 connect()를 호출하도록 했다. 

2) NetworkClient 클래스 테스트 코드 

1. 애플리케이션을 시작할 때 스프링 빈이 등록된다. 

    -> NetworkClient 클래스의 생성자에서 connect() 가 호출된다. 

// 스프링 컨테이너 생성
ConfigurableApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class);

2. 애플리케이션 종료할 때 스프링 컨테이너의 close() 를 호출한다. 

ac.close();

 출력 결과는 아래와 같다. 

너무 당연한 얘기지만, 빈이 등록될 때 생성자를 호출하는데 이 때는 url 이 없으니까 url 이 null 로 출력된다. 

3) 스프링 빈의 라이프 사이클 

객체 생성 -> 의존관계 주입 

스프링 빈은 객체를 생성하고, 의존관계 주입이 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다.

즉, 의존관계 주입이 끝나야 필드나 메서드를 변경하거나 사용할 수 있게 된다는 의미다. 필드를 수정하는 이러한 작업을 초기화 작업이라고 한다. 

객체 생성 -> 의존관계 주입 -> 초기화 작업 가능 시점 

4) 개발자는 초기화 작업을 할 수 있는 시점을 어떻게 알까 ?

스프링은 의존관계 주입이 끝나면, 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려준다. 

그리고 스프링 컨테이너가 종료되기 직전에, 소멸 콜백을 준다. 따라서 안전하게 종료 작업을 진행할 수 있다. 

스프링 빈의 이벤트 라이프사이클 

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용
-> 소멸전 콜백 -> 스프링 종료 

 * 초기화 콜백 : 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출되는 콜백.

 * 소멸전 콜백 : 빈이 소멸되기 직전에 호출되는 콜백.

5) 객체의 생성과 초기화를 분리하자 

생성자는 필수 정보만 파라미터로 받아서 메모리를 할당해서 객체를 생성하는 것만 해야 한다. 딱 생성하는 것에만 집중해야 한다. 

반면에 초기화는 외부 커넥션을 생성하는 등 무거운 동작을 수행한다. 

대부분의 경우, 둘을 합쳐놓는 것 보다는 객체 생성과 초기화를 분리하는 것이 유지보수 관점에서 좋다. 

물론 초기화 작업이 내부 값을 약간 변경하는 정도의 단순 작업이면 생성자에서 다 처리하는 것이 나을 수 있다. 

6) 객체의 생성과 초기화를 분리했을 때 장점

이런 것을 '지연' 이라고 하는데. 

예를 들어, DB 커넥션 풀을 애플리케이션 시작 할 때 100개 연결 생성만 만들어 둔다고 하자. 이 때 초기화는 안 한다. 
최초에 액션이 (실제 요청이) 들어오면 초기화를 해서 사용하는 동작을 지연시키는 장점이 있다. 

[ 참고 ] 

스프링 컨테이너가 종료될 때 싱글톤 빈들이 함께 종료된다. 그래서 스프링이 종료될 때 소멸전 콜백이 일어난다. 

뒤에서 '스코프'를 설명할 때 자세히 배우겠지만, 생명주기가 짧은 빈들은 스프링 컨테이너 종료와는 무관하게 해당 빈이 종료하기 직전에 소멸전 콜백이 일어난다. 

스프링은 3가지 방법으로 빈 생명주기 콜백을 지원한다. 다음 시간에 배우자. 

공부 내용 출처 :  스프링 핵심 원리 기본편 

목표

1. 다양한 의존관계 주입 방법 

2. 옵션 처리 

3. 생성자 주입을 선택해라!  

4. 롬복과 최신 트랜드

5. 조회 빈이 2개 이상 - 문제  (이번 포스팅)

6. @Autowired 필드 명, @Qualifier, @Primary

7. 애노테이션 직접 만들기

8. 조회한 빈이 모두 필요할 때, List, Map

9. 자동, 수동의 올바른 실무 운영 기준

5. 조회할 빈이 2개 이상일 때의 문제 해결하기

@Autowired 는 타입으로 빈을 조회한다.

1) 만약 타입이 같은 빈이 2개가 조회되면 문제가 생길까? 

인터페이스 DiscountPolicy의 구현체 2개가 있다. RateDiscountPolicy와 FixDiscountPolicy 는 타입이 같다. 

RateDiscountPolicy 만 컴포넌트 스캔으로 스프링 빈 등록했었는데. FixDiscountPolicy도 스프링 빈 등록하려고 한다. 

스프링 빈 등록을 위해 컴포넌트 스캔을 하자.

2) orderServiceImple 에서 의존성 예외 발생했는데, DiscountPolicy 싱글 빈이 매칭되기를 기대했는데, 2개가 발견됬기 때문이다. 

beans.factory.UnsatisfiedDependencyException: 
Error creating bean with name 'orderServiceImpl' Unsatisfied dependency 
nested exception is NoUniqueBeanDefinitionException: 
No qualifying bean of type 'DiscountPolicy' available: 
expected single matching bean but found 2: fixDiscountPolicy,rateDiscountPolicy

@Autowired 로 의존관계를 주입하려고 DiscountPolicy 타입의 스프링 빈을 뒤져봤더니

1개 매칭을 기대했는데, 2개의 스프링 빈이 RateDiscountPolicy와 FixDiscountPolicy 발견되서 에러가 났다. 

3) 하위 타입인 fixDiscountPolicy 나 rateDiscountPolicy 를 적어야 할까? 아니다. 하위타입에 의존하면 DIP를 위반한다. 

다음 시간에 해결책을 배워보자. 

6. @Autowired 필드 명, @Qualifier, @Primary

타입이 같은 빈이 여러개 조회되면, 3가지 방법으로 해결할 수 있다.

1) @Autowired 필드 명을 매칭한다

@Autowired 의 스프링 빈 조회 순서->   1. 타입 매칭,  2. 필드 명 또는 파라미터 명을 매칭 

@Autowired 는 가장 먼저 스프링 빈의 타입을 매칭해보고. 빈이 2개 이상 조회되면 필드 명을 확인해서 매칭되는 하나를 조회한다. 

이전 코드 

@Autowired 필드 명을 매칭시키도록 변경한 코드 

2) @Qualifier 추가 구분자를 붙여주기

추가적인 방법을 제공하는 것이지 빈 이름을 변경하는건 아니다. 

예를 들어, RateDiscountPolicy 에 @Qualifier("mainDiscountPolicy") 를 지정하고, 

FixDiscountPolicy 에는 @Qualifier("fixDiscountPolicy") 를 지정한다. 

생성자 주입을 할 때 @Qualifier를 써주면 된다.

만약 해당 @Qualifier를 못찾으면 스프링은 그 이름으로 등록된 빈을 찾아본다. 

@Qualifier의 스프링 빈 조회 순서->   1.  @Qualifier 끼리 매칭,  2. 빈 이름 매칭 

@Qualifier 는 @Qualifier 를 찾는 용도로만 사용하는게 명확하고 좋다. 헷갈리게 하는 요소를 만들지 말자. 

3) @Primary 우선순위를 지정하기 [ 편하고 자주 사용한다 ] 

rate 할인정책을 항상 먼저 적용하고 싶다면, RateDiscountPolicy에 @Primary 를 붙인다. 

생성자에는 DiscountPolicy 타입 그대로 둔다. 

[ 참고 ] @Primary 는 언제 사용할까? 

예를 들어, 메인 DB connection 을 주로 사용하고, 백업용 DB connection 이 있는 상황에서,

메인 DB connection 에 @Primary 를 걸어두자고 팀내에서 룰을 지정할 수 있다. 

다음 강의에서는 애노테이션을 직접 만드는 방법을 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편 

목표

1. 웹 애플리케이션과 싱글톤  (이번 포스팅)

2. 싱글톤 패턴 

3. 싱글톤 컨테이너 

4. [중요] 싱글톤 방식의 주의점  

5. @Configuration과 싱글톤

6. @Configuration과 바이트코드 조작의 마법 

1. 웹 애플리케이션과 싱글톤  

스프링은 태생이 온라인 서비스 기술을 지원하기 위해 탄생했다. 대부분의 스프링 애플리케이션은 웹 애플리케이션이다. 

웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다. 

고객 요청이 올 때마다 AppConfig가 객체를 새로 만들면? 요청이 올 때마다 인스턴스가 생성되는데.

1000개의 요청이 서버에 들어오면?? 1000개의 인스턴스가 메모리를 차지하게 된다. -> 메모리 낭비! 

해결 방안

객체를 딱 1개만 생성되도록 보장하고 이것을 공유하도록 설계하는 것이다. 

2. 싱글톤 패턴

1) 싱글톤 패턴으로 이 문제를 해결해보자.

싱글톤 패턴은 JVM 안에 클래스의 인스턴스가 딱 1개만 생성되는 방식이다. 

인스턴스를 2개 이상 생성하지 못하도록 막아야 한다! 코드로 확인해보자. 

핵심은 private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막는 것이다.

아래는 싱글톤 패턴 구현 코드다. 

public class SingletonService {

    // 1. 자기 자신을 내부에 private 으로 선언. final 이니까 딱 1번만 생성하고, 2번 생성 불가하게 만든다.
    private static final SingletonService instance = new SingletonService();

    // 2. 인스턴스 조회는 public 으로 열어둠
    public static SingletonService getInstance(){
        return instance;
    }

    // 3. 생성자를 private 으로 생성. 외부에서 new 키워드로 객체 생성 불가하도록 막음
    private SingletonService(){ 
    }

    public void logic(){
        System.out.println("싱글톤 객체 로직 호출");
    }
}

2) 싱글톤을 어떻게 구현할까? : 객체를 미리 생성하는 안전하고 단순한 방법으로 구현해보자. 

1. static 영역에 객체 instance를 미리 1개 생성해서 올려둔다.

    자바가 시작할 때 객체를 하나 생성해서 정적 (클래스) 영역에 상수처럼 가지고 있는 것이다. 이미 1개 생성 끝.

2. 인스턴스 조회할 수 있는 메서드를 public으로 열어뒀다.

    호출할 때 마다 최초에 1개 만들어둔 같은 객체 인스턴스가 반환된다. 

3. 인스턴스 생성은 private 으로 막아뒀다. 외부에서 new 키워드로 객체 생성 불가하게 만들었다. 

    new 키워드로 생성하려는 순간 컴파일 오류남! 세상에서 제일 좋은 오류 컴파일 오류. 

3) 이제 AppConfig를 전부 싱글톤 패턴으로 바꾸면 되겠네요?

-> 스프링 컨테이너는 객체 인스턴스를 싱글톤으로 관리한다. 이미 만들어진 객체를 공유한다. 

4) 싱글톤 패턴의 여러 문제점 

객체 마다 싱글톤 패턴 구현하는 코드 자체가 많이 들어간다. 객체 선언, 생성자 등등 구현 코드 필요 

의존관계상 클라이언트가 구체 클래스에 의존한다 -> DIP를 위반한다.

테스트하기 어렵다.

내부 속성을 변경하거나 초기화하기 어렵다.

private 생성자를 쓰니까, 자식 클래스를 만들기 어렵다. 

결론적으로 유연성이 떨어져서 안티패턴으로 불리기도한다. 

3. 싱글톤 컨테이너 

스프링 컨테이너는 싱글톤 패턴의 문제점은 싹 해결하고, 객체 인스턴스를 싱글톤으로 관리한다. 

1) 싱글톤 컨테이너 

스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다. 

이렇게 싱글톤 객체를 생성하고 관리하는 컨테이너를 싱글톤 레지스트리라 한다. 

싱글톤 패턴을 위한 지저분한 코드를 안 넣어도 된다. 

private생성자, DIP 위반 등의 단점을 해결하고 싱글톤을 사용할 수 있게 된다. 

2) 싱글톤 객체를 사용하는지 코드로 확인하자. 

MemberService.class 타입 빈을 2개 꺼내자.  참조값이 똑같은지 확인하자. 참조값이 똑같다!

3) 스프링 컨테이너 덕분에 여러개의 요청이 오더라도 이미 만들어진 객체를 공유해서 효율적으로 재사용할 수 있다. 

스프링 컨테이너는 기본 빈 등록 방식이 싱글톤이다. 

하지만 요청할 때 마다 새로운 객체를 생성해서 반환하는 기능도 제공하긴 한다. 하지만 99% 경우가 싱글톤을 쓴다.

자세한 내용은 뒤에 빈 스코프에서 배운다. 

4) 스프링 컨테이너의 싱글톤 패턴 확인하는 테스트 코드

[중요] 4. 싱글톤 방식의 주의점

실무에서 아래의 주의점을 안 지켜서 큰 장애가 발생하는 경우가 있다. 

스프링 컨테이너든, 싱글톤 패턴을 구현해서 사용하든
싱글톤 방식을 쓸 때 객체를 무상태로 설계해야 한다. 

1) 무상태(stateless)로 설계해야 한다는 의미가 뭘까? 

* 특정 클라이언트에 의존적인 필드가 있으면 안 된다. 

* 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안 된다. 

* 가급적 읽기만 가능해야 한다. 

* 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다. 

여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 상태유지(stateful)하게 설계하면 안 된다. 

2) 실무에서 자주 발생하는 문제 코드를 알아보자 

StatefulsService 의 order() 메서드 : 사용자가 주문하면 금액을 저장한다.

A사용자는 10000원, B사용자는 20000원 어치를 주문한다고 가정한다.  

사용자 A의 주문금액이 20000원으로 나온다.

StatefulService는 싱글톤 빈이니까. statefulService1 과 statefulService2 는 같은 객체다.

하나의 price 변수에 ThreadA와 ThreadB가 접근해서 값을 변경한 것이다. 

이러면 서비스 망하는거에요. 몇 년에 한 번씩 실무에서 꼭 만나는 상태유지 문제!! 이런 건 잡기도 어렵습니다.

원래는 실무를 반영하려면 멀티스레드 넣고 상속 관계 넣고 하는 복잡한 예제가 더 적절한데, 간단한 예제를 든 것이다. 

결론: 공유 필드는 조심하면서 무상태로 만들자!

3) 무상태 (Stateless)로 바꿔보자! 공유되지 않는 지역변수를 쓰자. 

공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

금액을 리턴값으로 넘기자. 

다음 강의에서는 '@Configuration과 싱글톤'을 배운다. 

프로젝트 레포지토리

공부 내용 출처 :  스프링 핵심 원리 기본편 

목표

1. 스프링 컨테이너 생성  

2. 컨테이너에 등록된 모든 빈 조회

3. 스프링 빈 조회 - 기본

4. 스프링 빈 조회 - 동일한  타입이 둘 이상 

5. [ 중요 ] 스프링 빈 조회 - 상속 관계

6. BeanFactory와 ApplicationContext 

7. 다양한 설정 형식 지원 - 자바 코드, XML (이번 포스팅)

8. 스프링 빈 설정 메타 정보 - BeanDefinition

7.  다양한 설정 형식 지원 - 자바 코드, XML

스프링 컨테이너는 다양한 설정 형식을 지원한다. 

자바 코드, XML, Groovy 등등.. 

애노테이션 기반 자바 코드로 설정

지금까지 애노테이션 기반 자바 코드로 설정(팩토리 빈으로 설정)하는 법을 배웠다.

AppConfig라는 팩토리 빈에서 @Bean 애노테이션이 달린 팩토리 메서드를 통해 스프링 빈을 스프링 컨테이너에 등록하는 방식이다. 

AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

XML로 설정

이번 시간에는 XML로 설정 해보자. 최근에는 스프링 부트를 많이 사용하면서 이 방식은 드물게 쓰고 있고, 레거시 프로젝트들에서 주로 사용한다. XML을 사용하면 컴파일 없이 빈 설정 정보를 변경할 수 있다는 장점이 있다.

1) resource 디렉토리에 appConfig.xml 을 작성한다. 

스프링 빈의 id, class, constructor-arg 등 으로 구성되어 있다. 이 때, class의 전체 경로를 적어줘야 한다.

내용은 자바 코드와 똑같은데 형식이 약간 다를 뿐이다. 

xml 기반 방식은 직접 스프링 빈을 스프링 컨테이너에 등록하는 방식이다. 

2) GenericXmlApplicationContext 에 appConfig.xml 설정 정보를 넘겨서 스프링 컨테이너를 생성한다. 

테스트 코드를 작성해서 memberService 빈을 조회해보자. 

xml 기반으로 설정하는 것은 최근에 잘 안쓰니까 이정도로 마무리하고. 필요하면 레퍼런스 문서를 확인하자. 

8. 스프링 빈 설정 메타 정보 - BeanDefinition

조금 깊이 있는 내용으로 가보자.  

1) 스프링은 어떻게 이런 다양한 설정 형식을 지원하는 것일까? 그 중심에는 BeanDefinition  이라는 추상화가 있다. 

• 즉, 역할과 구현을 개념적으로 나눈 것이다. 
  • XML 을 읽어서 BeanDefinition을 만들면 된다. 
  • 자바 코드를 읽어서 BeanDefinition을 만들면 된다.
  • 스프링 컨테이너는 자바 코드인지 XML 인지(구현은) 몰라도 된다. 오직 BeanDefinition만(역할만) 알면 된다. 

• BeanDefinition 을 빈 설정 메타정보라 한다. 
• 이 메타정보를 기반으로 인스턴스를 생성한다. 
• BeanDefinition 자체가 인터페이스다. 스프링 컨테이너는 인터페이스만 바라본다.
  • @Bean , <bean> 당 각각 하나씩 메타정보가 생성된다. 이 메타정보를 기반으로 스프링 빈을 생성한다. 

2) 코드 레벨로 들어가보자. 

아유 잘 모르겠다 싶으면 몰라도 된다. 개발에 아~무 지장없다. 

설정 형식 마다 Reader가 있다! 

• ApplicationContext 인터페이스에는 설정 파일을 읽기 위한 여러 구현체들이 있다. 
• 자바 코드 설정을 읽을 Reader == AnnotatedBeanDefinitionReader 가 있다. 얘가 AppConfig.class 파일을 읽어서 빈 메타정보를 생성한다. 
• xml 형식의 설정을 읽을 XmlBeanDefinitionReader 가 있다. 얘가 appConfig.xml을 읽어서 빈 메타정보를 생성한다. 
• 새로운 형식의 설정 정보가 추가되면, 또는 개발자가 새 형식의 설정 정보를 추가하면, XxxBeanDefinitionReader를 만들어서 BeanDefinition을 생성할 수 있다. 

[ 정리 ] 

스프링이 다양한 형태의 설정 정보를 BeanDefinition으로 추상화해서 사용하는 것 정도만 이해하면 된다. 

스프링 관련 오픈 소스를 보다가 BeanDefinition 이 보일 것이다. 이 때 이러한 매커니즘을 떠올리면 된다. 

다음 강의에서는 객체가 JVM안에 딱 하나만 있어야되는 '싱글톤 컨테이너와 싱글톤 방식의 주의점'를 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편 

목표

1. 스프링 컨테이너 생성  

2. 컨테이너에 등록된 모든 빈 조회

3. 스프링 빈 조회 - 기본

4. 스프링 빈 조회 - 동일한  타입이 둘 이상 (이번 포스팅)

5. [ 중요 ] 스프링 빈 조회 - 상속 관계

6. BeanFactory와 ApplicationContext 

7. 다양한 설정 형식 지원 - 자바 코드, XML

8. 스프링 빈 설정 메타 정보 - BeanDefinition

4. 스프링 빈 조회 - 동일한 타입이 둘 이상 

1) 타입으로 조회 시, 같은 타입이 2개 이상 있으면 중복 오류가 발생한다. 

임시로 MemberRepository 타입 빈이 2개 있는 SameBeanConfig.class 설정 파일을 만들었다. 

여기서 MemberRepository.class 타입 빈을 가져오면? 

아래와 같은 NoUniqueBeanDefinitionException 이 발생한다. 설명이 굉장히 친절하다.

싱글 매칭 빈을 기대했는데, 2개 였다는 내용. 

org.springframework.beans.factory.NoUniqueBeanDefinitionException
: No qualifying bean of type 'hello.corebasic.member.MemberRepository' available
: expected single matching bean but found 2: memberRepository1,memberRepository2

이렇게 특정 에러가 발생하는지 확인하려면 assertThrow와 Exception 클래스명을 써서 확인한다.

2) 타입으로 조회 시, 같은 타입이 2개 이상 있으면 빈 이름을 지정하면 된다!

빈 이름은 중복 불가다. 빈 이름을 안겹치게 지어서 조회하면 된다.

3) 특정 타입을 모두 조회하기

getBeansOfType() 메서드로 Map<이름, 타입> 특정 타입의 모든 빈을 모두 조회할 수 있다. 

나중에 @Autowired같이 자동으로 주입되는 기능을 배울 때 이런식으로 적용이 된다. 

ac.getBeansOfType(MemberRepository.class);

[ 중요 ] 5. 스프링 빈 조회 - 상속 관계 

1) 부모 타입으로 빈을 조회하면, 자식 타입도 함께 조회한다.

스프링 빈 대 원칙 하나는 "스프링 빈 하나 조회하면? 그 빈의 자식을 싹다 조회한다. " 

그래서 모든 자바 객체의 최고 부모인 Object 타입. Object 타입으로 조회하면, 모든 스프링 빈을 조회한다. 

테스트 코드로 확인하자. TestConfig 설정파일을 하나 만들자. DiscountPolicy 이름으로 생성될 빈이 2개다!  반환되는 생성자만 다르다. 

2) 부모 타입을 조회하면, 자식까지 다 딸려서 조회되니까 자식이 둘 이상인 경우 오류가 발생한다. 

이럴 땐 이름을 지어서 구분하면 된다. 

3) 부모 타입을 조회 시, 자식이 둘 이상 있으면, 빈 이름을 지정하면 된다. 

rateDiscountPolicy 특정 빈 이름으로 조회하자. 

4) 특정 하위 타입으로 조회할 수 있다. 

구체적인 타입으로 딱 지정하면 조회할 수 있지만 안 좋은 방법이다. 

5) 부모 타입으로 모두 조회해보자. 

할인 정책 인터페이스를 구현한 구현체 클래스 2개가 조회 된다. 

rateDiscountPolicy, fixDiscountPolicy 자식 타입 스프링 빈 2개가 출력됨을 확인할 수 있다. 

[ 참고 ] 실무에서 테스트 코드를 작성할 때는 이렇게 출력물을 만들면 안된다

지금은 공부용이라서 system.out.print를 하지만, 실무에서 테스트 코드를 작성할 때는 이렇게 출력물을 만들면 안된다. 

테스트 통과/실패 여부만 판단하도록 작성하는게 좋다. 

6) 최고 부모 타입인 Object 로 조회해보자. 

모든 자바 객체의 부모는 Object 라서. 모든 스프링 빈이 조회된다. 

7) 부모 타입으로 조회하면, 자식 타입도 함께 조회한다

실무에서는 ApplicationContext를 통해 getBean() 빈을 조회할 일이 거의 없다. 스프링 컨테이너가 자동으로 의존관계를 주입해주기 때문이다.

굳이 이렇게 배운 이유는, 빈 조회는 스프링의 기본 기능이기도 하고 아주 가끔 순수한 자바 애플리케이션에서 스프링 컨테이너를 생성해서 사용할 일이 있기 때문이다. 
그리고 부모 타입으로 조회 시, 자식 타입 빈까지 조회됨을 알고 있어야 자동 의존관계 주입을 배울 때 잘 사용할 수 있다.

6. BeanFactory 와 ApplicationContext

BeanFactory 와 ApplicationContext에 대해서 알아보자. 아래 계층 구조를 보자.

• 최상위에 있는 인터페이스 BeanFactory 가 있다.
• 최상위에 있는 인터페이스 BeanFactory를 상속받은 인터페이스 ApplicationContext 가 있다. 
• ApplicationContext 는 BeanFactory에 부가 기능을 더한 것이다. 

BeanFactory

• BeanFactory 는 스프링 컨테이너의 최상위 인터페이스다. 
• 스프링 빈을 관리하고 조회하는 역할을 담당한다. 지금까지 빈 조회에 사용한 getBean() 을 BeanFactory이 제공한 것이다. 

ApplicationContext 

• BeanFactory의 모든 기능을 상속 받아서 제공한다. 

BeanFactory와 ApplicationContext의 차이는 뭘까? 

• 애플리케이션을 개발할 때는 빈을 관리하고 조회하는 기능은 물론이고 수 많은 부가기능이 필요하다. 
• ApplicationContext는 아래와 같이 여러 인터페이스를 상속받아서 국제화, 이벤트, 리소스 조회 등의 기능을 제공한다. 
• 우리는 BeanFactory를 직접 사용할 일은 거의 없고, 빈 관리와 부가기능이 포함된 ApplicationContext를 사용한다. 

메시지 소스를 활용한 국제화 기능 

 : 예를 들어 한국에서 접속하면 한국어로, 영어권에서 접속하면 영어로 출력해준다 

환경 변수 

 : 로컬, 개발, 운영 등을 구분해서 환경 변수를 처리 

애플리케이션 이벤트

 : 이벤트를 발행하고 구독하는 모델을 편리하게 지원 

편리한 리소스 조회 

 : 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

BeanFactory 나 ApplicationContext를 스프링 컨테이너라 한다. 

다음 강의에서는 '스프링 컨테이너가 지원하는 자바코드, XML 형식의 설정 정보'를 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편 

지난 시간까지 순수 자바 코드로 만든 예제 프로젝트의 문제점을 개선하면서 스프링으로 전환해봤다.

그러면서 왜 스프링이 필요한지, 스프링의 DI 개념에 대해 배웠다. 이번 시간에는 스프링 그 자체에 대해 배운다. 

목표

1. 스프링 컨테이너 생성  (이번 포스팅)

2. 컨테이너에 등록된 모든 빈 조회

3. 스프링 빈 조회 - 기본

4. 스프링 빈 조회 - 동일한  타입이 둘 이상

5. 스프링 빈 조회 - 상속 관계

6. BeanFactory와 ApplicationContext 

7. 다양한 설정 형식 지원 - 자바 코드, XML

8. 스프링 빈 설정 메타 정보 - BeanDefinition

1. 스프링 컨테이너 생성 과정

이전 시간에 AppConfig.class를 넘겨서 생성한 스프링 컨테이너 코드를 떠올려보자. 

컨테이너라는게 '객체를 담고 있다'는 뜻이다. 

ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

ApplicationContext는 스프링 컨테이너다. 

ApplicationContext 는 인터페이스인데, 그것을 구현한 클래스가 AnnotationConfigApplicationContext다. 

스프링 컨테이너를 생성하는 방법에는 XML 기반과 애노테이션 기반이 있다.

우리가 AppConfig.class 에 @Configuration 애노테이션을 달고, 메서드에 @Bean을 달았는데. 이 방법이 애노테이션 기반 자바 설정 클래스로 스프링 컨테이너를 생성한 것이다.

참고 : 더 정확히는 스프링 컨테이너를 부를 때 BeanFactory와 ApplicationContext를 구분한다. 뒤에서 더 자세히 배운다. 

1) 스프링 컨테이너 생성 과정 

스프링 컨테이너를 생성 할 때 구성 정보(설정 정보)를 정해줘야 한다. 여기서는 AppConfig.class 를 구성 정보로 지정했다. 

2) 스프링 빈 등록

스프링 컨테이너는 파라미터로 넘어온 설정 클래스 정보를 사용해서 @Bean이 붙은 메서드의 반환 객체를 모두 스프링 빈으로 등록한다.

{ @Bean 이름 - @Bean 객체 } 쌍으로 컨테이너에 저장된다. 

아래에 코드를 보자. memberService() 메서드에 @Bean 애노테이션이 붙어있다. 

memberService 이름의 스프링빈은 아래의 쌍으로 저장된다. 

{ @Bean이름: memberService  - @Bean객체: new MemberServiceImpl(memberRepository())  }

빈 이름은 디폴트로 메서드 이름과 똑같이 정해지는데 직접 이름을 지을 수도 있다. 

주의: 빈 이름은 중복 불가

3) 스프링 빈 의존관계 설정 - 준비 

애노테이션 기반 자바 설정 클래스(AppConfig.class)를 기반으로 스프링 컨테이너를 생성한다. 

@Bean 을 달아놓은 메서드를 전부 호출하여 메서드 명 그대로 이름붙여서 컨테이너에 스프링 Bean으로 등록한다. 

4) 스프링 빈 의존관계 설정 - 완료 

스프링 컨테이너가 설정 정보를 참고해서 의존관계를 주입(DI) 한다. 

어떤 인터페이스에 어떤 구현체를 생성해서 인스턴스 레퍼런스를 넘길지 정보를 보고 의존관계를 주입한다. 

단순히 자바 코드를 호출하는 것 같아보이지만, 차이가 있다. 이 차이는 뒤에서 싱글톤 컨테이너에서 설명한다. 

[ 참고 ]

스프링 컨테이너는 빈을 생성하고 의존관계를 주입한다는 것이 핵심이다. 

스프링 빈을 생성하고 의존관계를 주입하는 단계를 나눠서 그림으로 그렸다. 사실 스프링에서는 이것이 한 번에 처리되는 것이고 이해를 위해 나눠 그린 것이다. 이제 스프링 컨테이너에서 데이터를 조회해보자. 

2. 컨테이너에 등록된 모든 빈 조회

테스트 코드를 작성해서 스프링 컨테이너에 스프링 빈이 등록되었는지 확인하자. 

테스트를 실행한 결과. 

파랗게 드래그한 부분은 appConfig.class를 포함해서 @Bean 을 달아놓은 스프링빈이 출력되었다. 

드래그한 윗 부분은 스프링이 내부적으로 스프링 자체를 확장하기 위해 필요한 스프링빈이다. 

스프링 내부적으로 필요한 것 말고, 내가 정의한 스프링 빈만 출력하자.  
getRole()== ROLE_APPLICATION : 개발을 위해 등록한 (일반적으로 사용자가 등록한) 빈만 출력된다. 

파랗게 드래그한 부분을 보면 appConfig.class를 포함해서 내가 정의한 빈 4개가 출력된다. 

3. 스프링 빈 조회 - 기본

1) getBean() 메서드로 빈 이름을 넘기면 스프링 빈을 조회할 수 있다. 

테스트 실행 결과, appConfig를 비롯한 스프링빈이 출력된다. 

2) 이름 없이 타입으로만 조회할 수 있다. 

memberService 빈 이름을 호출하지 않고, memberService.class 타입으로 빈을 조회할 수 있다. 

3) 구체 타입 으로 조회할 수 있다. 

memberService 빈을 호출하면 구체클래스 memberServiceImpl을 반환해준다. 

AppConfig.class 코드를 열어 보면 memberService 스프링 빈의 반환 타입을 확인할 수 있다. 

따라서 스프링 빈을 memberServiceImpl 구체 타입으로 조회 가능하다. 

좋은 코드는 아니다.

왜냐하면 프로그래머는 "추상화에 의존해야지, 구현체에 의존하면 안된다." 는 SOLID원칙을 다시 떠올리자! 

4) 존재하지 않는 빈을 조회해보자. 

테스트 작성 시, 항상 실패 케이스도 만들어야 한다. XXX 라는 이름의 빈을 조회하면, 없는 빈이니까. 아래의 예외가 터져야 한다. 

NoSuchBeanDefinitionException: No bean named 'XXX' available

XXX라는 빈 없다는 에러 내용을 확인할 수 있다.

빨간 글씨를 보긴 했지만 예쁘게 고쳐보자. 

5) 실패 케이스 "@@예외가 터지면 성공이다."라는 테스트를 작성하자. 

다음 시간에는 "동일한 타입의 빈이 2개 이상 있으면 어떻게 조회 하는지 " 알아보자. 

다음 강의에서는 '스프링 빈 조회와 BeanFactory'를 배운다. 

공부 내용 출처 :  스프링 핵심 원리 기본편