주입할 스프링 빈이 없어도 동작해야 할 때가 있다. 그런데 @Autowired 만 사용하면 required 옵션의 기본값이 true로 되어 있어서 자동 주입 대상이 없으면 오류 가 발생한다. 옵션 처리 자동 주입 대상을 옵션으로 처리하는 방법은 다음과 같다. @Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안된다. org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 null이 입력된다. Optional : 자동 주입할 대상이 없으면 Optional.empty 가 입력된다. 예제 1. @Autowired(required=false) required는 디폴트가 true이다. 자동 주입할 대상이 없으면 (Spri..
공부/Spring
다양한 의존관계 주입 방법 의존관계 주입은 크게 4가지 방법이 있다. 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 1. 생성자 주입 이름 그대로 생성자를 통해서 의존 관계를 주입 받는 방법이다. 지금까지 진행했던 방법이 바로 생성자 주입이다. 특징 생성자 호출시점에 딱 1번만 호출되는 것이 보장된다. 불변, 필수 의존관계에 사용 @Component public class OrderServiceImpl implements OrderService { private final MemberRepository memberRepository; private final DiscountPolicy discountPolicy; @Autowired public OrderServiceImpl(M..
중복 등록과 충돌 컴포넌트 스캔에서 같은 빈 이름을 등록하면 어떻게 될까? 다음 두가지 상황이 있다. 자동 빈 등록 vs 자동 빈 등록 수동 빈 등록 vs 자동 빈 등록 경우1. 자동 빈 등록 vs 자동 빈 등록 컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되는데, 그 이름이 같은 경우 스프링은 오류를 발생시킨다. ConflictingBeanDefinitionException 예외 발생 경우 2. 수동 빈 등록 vs 자동 빈 등록 만약 수동 빈 등록과 자동 빈 등록에서 빈 이름이 충돌되면 어떻게 될까? 이 경우 수동 빈 등록이 우선권을 가진다. (수동 빈이 자동 빈을 오버라이딩 해버린다.) @Component public class MemoryMemberRepository implements Membe..
includeFilters : 컴포넌트 스캔 대상을 추가로 지정한다. excludeFilters : 컴포넌트 스캔에서 제외할 대상을 지정한다. 예제 확인 테스트 코드에 추가 Annotation 만들기 컴포넌트 스캔 대상에 추가할 애노테이션 (@MyIncludeComponent 만들기) package hello.core.scan.filter; import java.lang.annotation.*; @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface MyIncludeComponent { } 컴포넌트 스캔 대상에서 제외할 애노테이션 (@MyExcludeComponent 만들기) package hel..
탐색할 패키지의 시작 위치 지정 모든 자바 클래스를 다 컴포넌트 스캔하면 시간이 오래 걸린다. 그래서 꼭 필요한 위치부터 탐색하도록 시작 위치를 지 정할 수 있다. basePackages : 탐색할 패키지의 시작 위치를 지정한다. 이 패키지를 포함해서 하위 패키지를 모두 탐색한다. basePackages = {"hello.core", "hello.service"} 이렇게 여러 시작 위치를 지정할 수도 있다. basePackageClasses : 지정한 클래스의 패키지를 탐색 시작 위치로 지정한다. 만약 지정하지 않으면 @ComponentScan 이 붙은 설정 정보 클래스의 패키지가 시작 위치가 된다.("hello.core") package hello.core; // 만약 지정하지 않으면 여기서 시작! /..
컴포넌트 스캔과 의존관계 자동 주입 시작하기 지금까지 스프링 빈을 등록할 때는 자바 코드의 @Bean이나 XML의 등을 통해서 설정 정보에 직접 등 록할 스프링 빈을 나열했다. (이전 게시글 : 빈 등록) 더보기 xml로 빈등록 자바 코드로 빈등록 @Configuration public class AppConfig { @Bean public MemberService memberService() { return new MemberServiceImpl(memberRepository()); } @Bean public OrderService orderService() { return new OrderServiceImpl( memberRepository(), discountPolicy()); } @Bean pub..
memberService → memberRepository() → MemoryMemberRepository() memberService 빈을 만드는 코드를 보면 memberRepository() 를 호출한다. 이 메서드를 호출하면 new MemoryMemberRepository() 를 호출한다. orderService → memberRepository() → MemoryMemberRepository() orderService 빈을 만드는 코드도 동일하게 memberRepository() 를 호출한다. 이 메서드를 호출하면 new MemoryMemberRepository() 를 호출한다. @Configuration public class AppConfig { @Bean public MemberService..
싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든, 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하 게 설계하면 안된다. ⭕ ⭐무상태(stateless) ⭐ 로 설계해야 한다!! ❌ 특정 클라이언트에 의존적인 필드가 있으면 안된다. ❌ 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다. → 스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있다!!! 가급적 읽기만 가능해야 한다. 필드 대신 자바에서 공유되지 않는, 지역변수, 파라미터, TreadLocal 등을 사용해야 한다. 상태를 유지할 경우 발생하는 문제점 예시 테스트 코드로 진행하겠다. Statefu..
스프링 컨테이너는 싱글톤 패턴의 문제(이전 포스트 참고)를 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다. 싱글톤 패턴의 문제는 간단히 말하자면, 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다. 의존관계상 클라이언트가 구체 클래스에 의존한다. 등 여러개가 있다. 싱글톤 컨테이너 스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다. 이전에는 아래 코드처럼 싱글톤을 생성해줬어야 했다. 더보기 https://sesam-dev.tistory.com/77 참고 package hello.core.singleton; public class SingletonService { // 1. static 영역에 객체를 딱 1개만 생성해둔다. private static fi..
싱글톤 패턴? 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다. 그래서 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다. private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다. Test 코드에서 진행한다. 싱글톤 패턴 적용 package hello.core.singleton; public class SingletonService { // 1. static 영역에 객체를 딱 1개만 생성해둔다. private static final SingletonService instance = new SingletonService(); // 2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용한다. ..
