developer h1 developer h1

스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생했다 대부분의 스프링 애플리케이션은 웹 애플리케이션이다 물론 웹이 아닌 애플리케이션 개발도 얼마든지 가능하다 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다 클라이언트 A, B, C 세명이 있다고 가정하자 세 사람이 동시에 memberService 를 요청했을 때, DI 컨테이너(AppConfig)는, memberService 객체를 세번 생성하여 반환해야 한다 실제 이렇게 동작하는지 코드로 테스트 해보자 hello.core.member.MemberServiceimpl@7d61eb55 hello.core.member.MemberServiceimpl@18ece7f4 로 다른 객체가 반환된 것을 볼 수 있다 언뜻보면 객체가 두개 생성 된 ..

스프링은 어떻게 이런 다양한 설정을 지원하는 것일까? 그 중심에는 BeanDefinition 이라는 추상화가 있다 쉽게 이야기해서 역할과 구현을 개념적으로 나눈 것 이다 - XML을 읽어서 BeanDefinition을 만들면 된다 - 자바 코드를 읽어서 BeanDefinition을 만들면 된다 - 스프링 컨테이너는 자바 코드인지, XML인지 몰라도 된다. 오직 BeanDefinition만 알면 된다 이때의 BeanDefinition을 빈 설정 메타 정보 라고 한다 - @Bean, 당 각각 하나의 메타 정보가 생성된다 스프링 컨테이너는 이 메타정보를 기반으로 스프링 빈을 생성한다 코드 레벨로 조금 더 깊게 들어가 보자 - AnnotationConfigApplicationContext 는 AnnotatedB..

스프링 컨테이너는 다양한 형식의 설정 정보를 받아들일 수 있게 유연하게 설계되어 있다 - 자바 코드, XML, Groovy 등등 에노테이션 기반 자바 코드 설정 사용 - 지금까지 했던 것이다 - new AnnotationConfigApplicationContext(AppConfig.class) - AnnotationConfigApplicationContext 클래스를 사용하면서 자바 코드로된 설정 정보를 넘기면 된다 XML 설정 사용 - 최근에는 스프링 부트를 많이 사용하면서 XML기반의 설정은 잘 사용하지 않는다. 아직 많은 레거시 프로젝트 들이 XML로 되어 있고, 또 XML을 사용하면 컴파일 없이 빈 설정 정보를 변경할 수 있는 장점도 있으므로 한번쯤 배워두는 것도 괜찮다 - GenericXmlAp..

BeanFactory - 스프링 컨테이너의 최상위 인터페이스이다 - 스프링 빈을 관리하고 조회하는 역할을 담당한다 - getBean() 을 제공한다 - 지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능이다 ApplicationContext - BeanFactory의 기능을 모두 상속받아서 제공한다 - 빈을 관리하고 검색하는 기능은 이미 BeanFactory가 제공해주는데, 둘의 차이가 뭘까? - 애플리케이션을 개발할 때는 빈은 관리하고 조회하는 기능은 물론이고, 수 많은 부가기능이 필요하다 ApplicationContext가 제공하는 기능 - 메시지 소스를 활용한 국제화 기능 - 예를 들어서 한국에서 들어오면 한국어로, 영어권에서 들어오면 영어로 출력 - 환경변수 - 로컬, ..

부모 타입으로 조회하면, 자식 타입도 함께 조회한다 그래서 모든 자바 객체의 최고 부모인 Object 타입으로 조회하면, 모든 스프링 빈을 조회한다 getBean으로 조회시 자식 타입이 둘 이상이면 오류가 나는 모습 다시한번 NoUniqueBeanDefinitionException 이 맞는지 assertThrows로 검증 빈 이름을 지정하여 특정 자식의 리턴 객체가 RateDiscountPolicy가 맞는지 확인 특정 하위 타입으로 조회하는 방법 부모 타입으로 모두 조회하는 방법 실제 테스트 코드를 짤 때, 이런 출력문을 사용하면 안된다 학습용으로만 사용하자 Object 타입으로 조회한 결과다 내 화면에는 어째선지 로그가 나오지 않았는데, 강사님 화면에는 스프링 빈의 기초적인 빈 까지 모두 함께 조회가 ..

타입으로 조회시 같은 타입의 스프링 빈이 둘 이상이면 오류가 발생한다 이때는 빈 이름을 지정하자 ac.getBeansOfType() 을 사용하면 해당 타입의 모든 빈을 조회할 수 있다 이와같이 새로운 @Configuration 에 같은 타입의 빈을 둘 이상 만들고, ac.getBean으로 호출하자 NoUniqueBeanDefinitionException에러가 뜨는 모습이다 실패하는 테스트와, 빈 이름을 지정하여 성공하는 테스트 두가지를 모두 완성했다 memberRepository 1, 2 를 둘다 꺼내고 싶다면 어떻게 할까 ac.getBeanOfType 을 사용하면 맵 형태로 자동 완성된다 iterator를 사용해 sout로 출력해서 확인하고, beansOfType 도 통으로 출력해 봤다 그리고 간략하게..

스프링 빈을 조회하는 가장 간단한 방법부터 알아보자 ac.getBean(빈이름, 타입) ac.getBean(타입) 조회 대상 스프링 빈이 없으면 예외 발생 - NoSuchBeanDefinitionException: No bean named 'xxxxx' available soutv 대신 Assertions 로 검증하는게 더 좋다 memberService 의 인스턴스가 MemberServiceimpl 이면 성공 타입만 가지고도 검증할 수 있다 구체 타입을 직접 조회할 수도 있다 memberService 안에 MemberServiceimpl 이 존재하면 성공한다 이걸 굳이 시도해 본 이유는 '인스턴스의 타입' 을 검증하는 것을 증명하기 위해서 이다 이전에 말했듯이 구현체에 의존하는 것은 좋지 않기 때문에 인..

스프링 컨테이너에 실제 스프링 빈들이 잘 등록 되었는지 확인해보자 위는 스프링이 내부적으로 확장하기 위해서 쓰는 기반 빈들이다 appConfig도 스프링 빈에 등록이 된다 그 밑에 4개의 이름들이 내가 등록한 것들이다 내게 필요한 정보는 밑에 5개 뿐인데, 그것들만 나오게 만들어 보자 ApplicationBean 이라는 것을 출력해 보자 모든 빈 출력하기 - 실행하면 스프링에 등록된 모든 빈 정보를 출력할 수 있다 - ac.getBeanDifinitionNames() : 스프링에 등록된 모든 빈 이름을 조회한다 - ac.getBean() : 빈 이름으로 빈 객체(인스턴스)를 조회한다 애플리케이션 빈 출력하기 - 스프링이 내부에서 사용하는 빈은 제외하고, 내가 등록한 빈만 출력할 수 있다 - 스프링이 내부..