developer h1 developer h1

필터 - 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는 같은 객체..

싱글톤 컨테이너 - 스프링 컨테이너는 싱글톤 패턴의 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다 지금까지 우리가 학습한 스프링 빈이 바로 싱글톤으로 관리되는 빈이다 - 스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다 - 이전에 설명한 컨테이너 생성 과정을 자세히 보자. 컨테이너는 객체를 하나만 생성해서 관리한다 - 스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다 - 스프링 컨테이너의 이런 기능 덕분에 싱글턴 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다 - 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도 된다 - DIP, OCP, 테스트, private 생..

싱글톤 패턴 - 클래스의 인스턴스가 딱 1개면 생성되는 것을 보장하는 디자인 패턴이다 - 그래서 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다 - private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다 말로 설명하면 와닿지 않는다 코드로 설명한다 1. static 영역에 객체 instance를 미리 하나 생성해서 올려둔다 2. 이 객체 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 조회할 수 있다 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다 3. 딱 1개의 객체 인스턴스만 존재해야 하므로, 생성자를 private으로 막아서 혹시라도 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막는다 private으로 막아놨기에 객체..