developer h1 developer h1

다양한 의존관계 주입 방법 의존관계 주입은 크게 4가지 방법이 있다 - 생성자 주입 - 수정자 주입(setter 주입) - 필드 주입 - 일반 메서드 주입 생성자 주입 - 이름 그대로 생성자를 통해서 의존관계를 주입 받는 방법이다 - 지금까지 우리가 진행했던 방법이 바로 생성자 주입이다 특징 - 생성자 호출시점에 딱 1번만 호출되는 것이 보장된다 - 불변, 필수 의존관계에 사용 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입 된다 물론 스프링 빈에만 해당한다 테스트 해보자 생성자에 @Autowired 를 제거했다 테스트 결과 @Autowired 가 있을 때 처럼 알아서 생성자 주입이 되는 모습이다 수정자 주입 - setter라 불리는 필드의 값을 변경하는 수정자 메서드를 통해서 주입하..

컴포넌트 스캔에서 같은 빈 이름을 등록하면 어떻게 될까? 다음 두가지 상황이 있다 1. 자동 빈 등록 vs 자동 빈 등록 2. 수동 빈 등록 vs 자동 빈 등록 자동 빈 등록 vs 자동 빈 등록 - 컴포넌트 스캔에 의해 자동의로 스프링 빈이 등록되는데, 그 이름이 같은 경우 스프링은 오류를 발생시킨다 - ConflictingBeanDefinitionException 예외 발생 실험해 보자 두 서비스 구현체에 service라는 동일한 이름을 주었다 에러가 나는 모습 아래는 오류 메시지의 일부다 Annotation-specified bean name 'service' for bean class 어노테이션인 '서비스'가 문제를 일으켰다고 한다 확인했으면 다시 원상 복구... 이와같이 자동 빈 등록 vs 자동 ..

필터 - includeFilters : 컴포넌트 스캔 대상을 추가로 지정한다 - excludeFilters : 컴포턴트 스캔에서 제외할 대상을 지정한다 예제로 확인해 보자 @Target 에 대한 어노테이션은 따로 공부가 필요하다고 한다 지금은 가볍게 사용하기 위해 @Component의 구현으로 들어가 위에 있는 어노테이션 3개를 복사해서 붙혀넣었다 참고로 파일을 클래스, 인터페이스가 아니라 가장 밑에 어노테이션으로 만들었다 이런식으로 어노테이션을 만들 수 있다 클래스 BeanA 에는 방금 만든 @MyIncludeComponent 를, 클래스 BeanB 에는 @MyExcludeComponent 를 넣었다 @Configuration 을 만들어 includeFilters 에 MyIncludeComponent ..

basePackages를 사용하면 탐색 시작 패키지를 지정할 수 있다 member 패키지의 하위 클래스만 스캔을 하고, 나머지는 등록되지 않았다 로그로 확인할 수 있는데... 내 로그가 왜 자세히 안나오는지 나중에 좀 알아봐야 겠다 basePackaged : 탐색할 패키지의 시작 위치를 지정한다. 이 패키지를 포함해서 하위 패키지를 모두 탐색한다 - basePackages = {"hello.core", "hello.service"} 이렇게 여러 시작 위치를 지정할 수도 있다 - basePackageClasses : 지정한 클래스의 패키지를 탐색 시작 위치로 지정한다 - 만약 지정하지 않으면 @ComponentScan 이 붙은 설정 정보 클래스의 패키지가 시작 위치가 된다 (@ComponentScan 이 ..

컴포넌트 스캔과 의존관계 자동 주입 시작하기 - 지금까지는 스프링 빈을 등록할 때는 자바 코드의 @Bean이나 XML의 등을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열했다 - 예제에서는 몇개가 안되었지만, 이렇게 등록해야 할 스프링 빈이 수십, 수백개가 되면 일일이 등록하기도 귀찮고, 설정 정보도 커지고, 누락하는 문제도 발생한다 역시 개발자는 반복을 싫어한다 - 그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다 - 또 의존관계도 자동으로 주입하는 @Autowired 라는 기능도 제공한다 먼저 기존 AppConfig.java 는 과거 코드와 테스트를 유지하기 위해 남겨두고, 새로운 AutoAppConfig.java를 만들자 참고: 컴포넌트 스캔을..

스프링 컨테이너는 싱글톤 레지스트리다 따라서 스프링 빈이 싱글톤이 되도록 보장해주어야 한다 그런데 스프링이 자바 코드까지는 어떻게 하기는 어렵다 AppConfig 자바 코드를 보면 분명 3번 호출되어야 하는 것이 맞다 그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다 모든 비밀은 @Configuration을 적용한 AppConfig에 있다 이전에 말했듯이 AppConfig 자체도 스프링 빈에 등록이 된다 한번 추출해서 .getClass()로 클래스를 확인해 보자 정상적인 클래스 정보 뒤에 의미를 알 수 없는 문자가 있다 $$SpringCGLIB$$0 이것은 내가 만든 클래스가 아니라 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 ..

@Configuration에 비밀에 대해 하나씩 파헤쳐 보자 AppConfig을 다시 살펴보자 memberService 를 호출하면, new MemoryMemberRepository 객체가 생성된다 또 orderService 를 호출하면, new MemoryMemberRepository 객체가 생성된다 결국 두개의 객체를 생성했으니, 이는 싱글톤이 깨진것이 아닐까? 스프링 컨테이너는 이 문제를 어떻게 해결할까? 직접 테스트 해보자 놀랍게도 memberService의 memberRepository 와 orderService의 memberRepository 는 같은 객체라는걸 알 수 있다 또한 직접 memberRepository 를 출력한 것도 똑같은 객체이다 AppConfig 에서 직접 메서드가 호출 될 ..

싱글톤 방식의 주의점 - 싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든, 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 객체는 상태를 유지(stateful)하게 설계하면 안된다 - 무상태(stateless)로 설계해야 한다 - 특정 클라이언트에 의존적인 필드가 있으면 안된다 - 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다 - 가급적 읽기만 가능해야 한다 - 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다 - 스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다 이번에도 코드로 예시를 확인하자 statefulService 1, 2는 같은 객체..