발자국남기기

1. 인터페이스 InitializingBean, DisposableBean 앞서 만든 NetworkClient 클래스를 InitializingBean과 DisposableBean의 구현체로써 구현해보자. InitializingBean의 구현메서드 afterPropertiesSet은 객체를 생성하고 의존관계 주입이 끝나면 호출되는 메서드이다. DisposableBean의 구현메서드 destroy는 스프링 컨테이너가 close될 때 스프링 빈들이 하나씩 소멸되면서 호출된다. 따라서 안전하게 연결을 종료할 수 있도록 해준다. 이제 테스트를 다시 실행해보자. 객체 생성 후 초기화 메서드(afterPropertiesSet)과 소멸 전 destory메서드를 확인할 수 있다. 하지만 초기화, 소멸 인터페이스에는 단점..

DB Connection pool이나, Network Socket처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다.(java와 db연결할 때 conn객체 사용하여 연결 초기화하고 종료하는 작업을 뜻함.) 스프링을 통해 이러한 초기화 작업과 종료 작업을 어떻게 진행하는지 알아보자. 간단하게 외부 Network에 미리 연결하는 객체를 하나 생성한다고 가정. (실제로 네트워크에 연결하는 것이 아니라 단순 문자만 출력하도록) 테스트 코드 여기서는 컨테이너를 종료(close)하기 위해 상위 클래스인 ConfigurableApplicationContext를 사용했다. 이제 테스트를 돌려보면 url에 nu..

편리한 자동 기능을 기본으로 사용하자! 그러면 어떤 경우에 컴포넌트 스캔과 자동 주입을 사용하고, 어떤 경우에 설정 정보(AppConfig)를 통해서 수동으로 빈을 등록하고 의존관계를 수동으로 주입해야 할까? 결론부터 얘기하면, 스프링이 나오고 시간이 갈 수록 점점 자동을 선호하는 추세이다. 스프링은 @Component 뿐만 아니라 @Controller, @Service, @Repository 처럼 계층에 맞추어 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한다. 추가로 최근 스프링 부트는 컴포넌트 스캔을 기본으로 사용하고, 스프링 부트의 다양한 스프링 빈들도 조건이 맞으면 자동으로 등록하도록 설계했다. 설정 정보를 기반으로 애플리케이션을 구성하는 부분과 실제 동작하는 부분을 명확하게 나누..

의도적으로 해당 타입의 스프링 빈이 다 필요한 경우도 있다. 예를 들어, 할인 서비스를 제공하는데 클라이언트가 할인의 종류를 선택할 수 있다면? 스프링을 사용하여 해결해보자. 위와 같이 테스트 코드를 작성하였다. 전에 만들어놓았던 AutoAppConfig를 통하여 컴포넌트 스캔을 진행하여 스프링 빈으로 등록한다.(@Component가 붙은 클래스 모두 등록) 그리고 우리가 static으로 만든 DiscountService또한 스프링 빈으로 등록시키는데 의존관계 주입시 List와 Map형태로 RateDiscountPolicy와 FixDiscountPolicy를 주입할 것이다. 테스트를 실행시켜보면 다음과 같이 Map와 List에 조회된 모든 빈들이 들어가있고, discountService 또한 정상적으로 ..

의존관계 주입은 크게 4가지가 있다. 1. 생성자 주입 2. 수정자 주입(setter 주입) 3. 필드 주입 4. 일반 메서드 주입 생성자 주입 이름 그대로 생성자를 통해서 의존 관계를 주입 받는 방법이다. 지금까지 진행했던 방법이 바로 생성자 주입 특징 생성자 호출 시점에 딱 1번만 호출되는 것이 보장 불변, 필수 의존관계에 사용 불변 한번 생성되면 바뀌지 않음 간단히 말하여 변할 수 없게 setter와 같이 수정할 수 있는 메소드를 만들지 않아야함 필수 관례적으로 생성자에는 값을 다 채워넣어야함. null을 허용한다고 명시되어있는 것이 아닌 경우에는 생성자가 딱 1개만 @Autowired를 생략해도 자동 주입된다.(스프링 빈에만 해당) 수정자 주입(setter 주입) setter라 불리는 필드의 값을..

@Configuration 과 Singleton Singleton이 무엇인지 Spring Container를 통해 이를 유지하는 것을 확인해보았다. AppConfig를 다시 보자 스프링이 초기화되어 스프링 컨테이너에 Bean들이 등록될 때를 생각해보자. memberService() -> memberRepository() 호출 이는 new MemoryMemberRepository()를 호출 orderService() -> memberRepository()호출 new MemoryMemberRepository()호출 응?? 이렇게되면 MemoryMemberRepository가 2개가 생성되어 싱글톤이 깨지는 것이 아닌가?? 직접 테스트를 해보자! 먼저, MemberServiceImpl 과 OrderServic..

스프링 컨테이너는 다양한 형식의 설정 정보를 받아드릴 수 있게 유연하게 설계되어 있다. java XML Groovy 등등 임의로 구현하여 새로운 설정 정보 형식을 사용할 수 있음 XML 설정 사용해보기 최근에는 Spring Boot를 많이 사용하면서 XML기반의 설정은 잘 사용하지 않는다. 하지만 아직 많은 레거시 프로젝트들이 XML로 되어있고, XML을 사용하면 컴파일 없이 빈 설정 정보를 변경할 수 있는 장점도 있으므로 알아두어서 나쁠 것은 없다. GenericXmlApplicationContext를 사용하여 xml 설정 파일을 넘기면 된다. 테스트 코드 XML 설정 파일 일반적으로 java코드를 제외한 나머지 파일들은 resources 폴더 내부에 놓는다. Spring Config로 작성할 XML문..

기본 스프링 컨테이너에서 스프링 빈을 찾는 가장 기본적인 조회 방법 ac.getBean(빈이름, 타입) ac.getBean(타입) 조회 대상 스프링 빈이 없으면 예외 발생 NosuchBeanDefinitionException : No bean named "빈이름" available 1. 빈 이름으로 조회!! Assertions로 검증 memberService가 어떤 객체 인스턴스인지?(isInstanceOf) MemberServiceImpl의 인스턴스라면 테스트 통과 테스트 성공 2. 이름 없이 타입으로만 조회 테스트 성공! 하지만 같은 타입이 여러 개일 경우에는 곤란해질 수 있음. 3. 구체 타입으로 조회 테스트 성공! 스프링 컨테이너에 구현체가 등록만 되어있으면 조회가 됨 스프링 빈에 등록되어 있는 ..

스프링 컨테이너에서 실제 스프링 빈들이 잘 등록 되었는지 확인해보자. Junit 테스트 코드로 작성 1. 모든 빈 출력 Bean명과 담겨있는 객체들을 출력하였다. 위의 org.springFramework ~~ 들은 스프링이 내부적으로 스프링 자체를 확장하기 위해 쓰는 Bean들이다. ac.getBeanDefinitionNames() : 스프링에 등록된 모든 빈 이름을 조회 ac.getBean() : 빈 이름으로 빈 객체(인스턴스)를 조회 2. 애플리케이션 빈 출력 getBeanDefinition : Bean에 대한 메타데이터 정보 getRole() : Bean의 역할을 가져오는 메소드 getRole이 ROLE_APPLICATION이라는 뜻은 스프링이 내부적으로 등록한 Bean이 아니라 우리가 Applic..

스프링 컨테이너😙 ApplicationContext 를 스프링 컨테이너라 한다. ApplicationContext 는 인터페이스이다. 스프링 컨테이너는 XML을 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다. 직전에 AppConfig 를 사용했던 방식이 애노테이션 기반의 자바 설정 클래스로 스프링 컨테이너를 만든 것 이다. 자바 설정 클래스를 기반으로 스프링 컨테이너( ApplicationContext )를 만들어보자. new AnnotationConfigApplicationContext(AppConfig.class); 이 클래스는 ApplicationContext 인터페이스의 구현체이다. > 참고: 더 정확히는 스프링 컨테이너를 부를 때 BeanFactory , Appli..