발자국남기기

컴포넌트 스캔에서 같은 빈 이름을 등록하면 어떻게 될까? 1. 자동 빈 등록 vs 자동 빈 등록 (둘다 컴포넌트 스캔) 2. 수동 빈 등록 vs 자동 빈 등록 자동 빈 등록 vs 자동 빈 등록 중복 등록되는 경우 스프링은 오류를 발생시킨다. ConflictingBeanDefinitionException 수동 빈 등록 vs 자동 빈 등록 위는 우리가 @Component 애노테이션을 붙혀 자동으로 빈 등록되는 클래스이다. 이와 똑같은 빈 이름(memoryMemberRepository)을 가진 빈을 수동으로 등록시켜보겠다. 실행시켜보니 충돌이 발생하지 않고 테스트가 성공한 것을 확인할 수 있다. 콘솔로그를 살펴보자. 다른 정의에 의해 오버라이딩되었다는 로그가 있다. 즉, 이러한 경우네는 수동 빈 등록이 우선권..

includeFilters : 컴포넌트 스캔 대상을 추가로 지정 excludeFilters : 컴포넌트 스캔에서 제외할 대상을 지정 먼저, 애노테이션을 만들어보자. 클래스 타입에 붙는 애노테이션이라는 의미이다. @MyIncludeComponent가 붙으면 컴포넌트 스캔에 추가 @MyExcludeComponent가 붙으면 컴포넌트 스캔에서 제외 하도록 만들어보려한다. 컴포넌트 대상으로 추가할 BeanA 컴포넌트 대상에서 제외할 BeanB Config설정 클래스에서 Filter를 만들어 Test하기 includeFilters를 사용하여 Filter타입은 ANNOTATION으로, MyIncludeComponent 애노테이션이 붙은 클래스들은 컴포넌트 대상에 추가 excludeFilters를 사용하여 Filte..

탐색할 패키지의 시작 위치 지정 모든 클래스를 다 컴포넌트 스캔하면 시간이 오래 걸린다. 그래서 꼭 필요한 위치부터 스캔하도록 시작 위치를 지정할 수 있다. basePackages를 사용하여 스캔할 범위를 지정한다. 위와 같이 작성하면 member패키지 내에서만 컴포넌트 스캔을 진행하여 memberServiceImpl과 memberMemberRepository만 빈으로 등록된다. 확인해보면 위와 같이 3개만 빈으로 등록된 것을 확인할 수 있다. basePackages = {"hello.core", "hello.service"} 와 같이 여러 시작 위치를 지정할 수도 있다. basePackages : 탐색할 패키지의 시작 위치를 지정한다. 이 패키지를 포함해서 하위 패키지를 모두 탐색한다. basePack..

지금까지 스프링 빈을 등록할 때는 자바 코드의 @Bean이나 XML의 등을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열했다. 이렇게 등록해야할 빈이 수십, 수백개가 되면 일일이 등록하기도 귀찮고, 설정 정보도 커지고, 누락하는 문제도 발생한다. 그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다. 또 의존관계도 자동으로 주입하는 @Autowired라는 기능도 제공한다. @ComponentScan 애노테이션은 @component가 붙은 클래스를 모두 스캔하여 스프링 빈으로 등록해준다. @Configuration또한 컴포넌트 스캔의 대상이므로 Filter를 사용하여 제외시켜주었다. 앞서 만든, AppConfig나 TestConfig등 @Configura..

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

싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든, 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다. 무상태(stateless)로 설계해야 한다!! (Restful API에 대해 알아볼 때 본 그 stateless!!) 특정 클라이언트에 의존적인 필드가 있으면 안된다. 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다. 가급적 읽기만 가능해야 한다. 가급적이면 수정을 하면 안된다는 의미 필드 대신에 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다. 참고 : docs.oracle.com/en/java/javase/11/..

싱글톤 패턴(Singleton Pattern)😁 클래스의 인터스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다. 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다. private 생성자를 사용하여 외부에서 임의로 new 키워드를 사용하지 못하게 해야함. 여기에는 Java의 static이라는 개념이 필요하다. wikidocs.net/228 위키독스 온라인 책을 제작 공유하는 플랫폼 서비스 wikidocs.net 이 클래스가 실행되어 JVM이 읽게되면 먼저 static영역에 instance 객체를 하나 생성한다. 후에 이 객체 인스턴스가 필요하면 getInstance를 통해서만 가져올 수 있다. 이는 항상 같은 인스턴스를 반환한다. 새로 생성하는 것이 아닌 미리 만들어두고 계속 가져다 쓰는 것 ..

Singleton pattern을 정보처리기사 시험을 준비하며 디자인 패턴의 생성패턴 중 하나로 알고 있었는데 이것은 객체 인스턴스가 오직 1개만 생성되야하는 경우에 사용하는 패턴이다. 예를 들어, 설정 파일같은 경우에는 객체가 여러 개 생성되면 설정 값이 변경될 위험이 생기므로 싱글톤을 사용해야한다. 싱글톤을 이용하게 되면 하나의 인스턴스를 메모리에 등록해서 여러 스레드가 동시에 해당 인스턴스를 공유하여 사용하게끔 할 수 있으므로, 요청이 많은 곳에서 사용하면 효율성이 높아지는 장점이 있다. (하지만 동시성 문제 고려해야함) 웹 애플리케이션과 싱글톤 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 하게 된다. 요청이 들어오면 AppConfig는 직접 객체를 만들어 반환시켜준다. 클라이언트 B(다른고객..

앞서 스프링이 다양한 설정 형석을 지원하는 것을 확인해보았다. 어떻게 지원하는 것일까? 그 중심에는 BeanDefinition이 있다. 이것은 역할과 구현을 개념적으로 나눈 것이다 XML을 읽어서 BeanDefinition을 만든다. Java 코드를 읽어서 BeanDefinition을 만든다. 즉, 스프링 컨테이너는 어떤 코드인지를 아는 것이 아니라, BeanDefinition을 알고 있는 것이다. "BeanDefinition"을 빈 설정 메타정보라 한다. Java의 '@Bean' / XML의 각각 하나씩 메타 정보가 생성된다. 스프링 컨테이너는 이 메타정보를 기반으로 Bean을 생성한다. 즉, 스프링 컨테이너는 BeanDefinition에만 의존한다. AnnotationConfigApplicationC..

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