발자국남기기

웹 스코프는 웹 환경에서만 동작하고, 스프링이 해당 스코프의 종료시점까지 관리하므로 종료 메서드가 호출된다. 웹 스코프 종류 request : HTTP요청 하나가 들어오고 나갈 때까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고 관리된다. session : HTTP Session과 동일한 생명주기를 가지는 스코프 application : 서블릿 컨텍스트(ServletContext)와 동일한 생명주기를 가지는 스코프 websocket : 웹 소켓과 동일한 생명주기를 가지는 스코프웹 환경에서만 동작하고, 스프링이 해당 스코프의 종료시점까지 관리하므로 종료 메서드가 호출된다. 클라이언트 A와 B는 서로 다른 빈 인스턴스를 가지게된다. request 스코프 만들기 웹 환경 추가 웹 ..

스프링 컨테이너에 프로토타입 스코프의 빈을 요청하면 항상 새로운 객체 인스턴스를 생성해서 반환한다. 하지만 싱글톤 빈과 함께 사용할 때는 의도한 대로 잘 동작하지 않으므로 주의해야 한다. 프로토타입 빈 직접 요청 클라이언트 A는 스프링 컨테이너에 프로토타입 빈을 요청 스프링 컨테이너는 프로토타입 빈을 새로 생성해서 반환(x01)한다. 해당 빈의 count 필드 값은 0이다. 클라이언트는 조회한 프로토타입 빈에 addCount()를 호출하여 count필드를 +1한다. 결과적으로 프로토타입 빈(x01)의 count 필드의 값은 1이다. 클라이언트 B는 스프링 컨테이너에 프로토타입 빈을 요청한다. 스프링 컨테이너는 프로토타입 빈을 새로 생성하여 반환(x02)한다. 해당 빈의 count 필드 값은 0이다. 클라..

빈 스코프 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료될 때까지 유지되는 것으로 알고있었는데, 이것은 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문이다. 스코프란 빈이 존재할 수 있는 범위를 뜻한다. 스프링이 지원하는 스코프 싱글톤 기본 스코프 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프 프로토타입 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프 의존관계 주입 후, 초기화 메서드까지 불러줌. 그 이후는 클라이언트에게 반환해주고 스프링이 관리하지 않음.(종료 메서드 호출X) 웹 관련 스코프(웹 관련 기능이 들어가야 쓸 수 있는 스코프) request : 웹 요청이 들어오고 나갈때..

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 또한 정상적으로 ..

@Qualifier("mainDiscountPolicy") 이렇게 코드를 작성하면 컴파일시 타입 체크가 안된다. 컴파일 중에 오류를 잡을 수가 없다는 의미이다.("mainnDiscountPolicy"라고 오타를 내도 컴파일은 되고 그 이후에 Exception이 발생한다.) 이를 애노테이션을 만들어서 해결해보자. 위와 같이 "mainDiscountPolicy"를 Qualifier로 가지는 애노테이션을 생성하였다. 이제 우리는 @MainDiscountPolicy를 가져다가 사용하면 되는 것이다. 위와같이 오타를 발생하면 컴파일 전에 오류를 잡아낼 수 있어진다. 이제 OrderServiceImpl의 생성자 주입에 우리가 만든 애노테이션을 넣어주면 스프링이 어떤 타입의 할인정책을 사용해야하는지 알게되는 것이다...

@Autowired는 타입으로 조회한다. 타입으로 조회하게 되면 선택된 빈이 2개 이상일 때 문제가 발생한다. DiscountPolicy의 구체인 FixDiscountPolicy와 RateDiscountPolicy 둘 다 스프링 빈으로 등록시키고 DiscountPolicy타입으로 조회를 하면 Exception이 발생한다. 하위 타입으로 지정할 수도 있지만, 하위 타입으로 지정하는 것은 DIP를 위배하고 유연성이 떨어진다. 그리고 이름만 다르고, 완전히 똑같은 타입의 스프링 빈이 2개 있을 때 해결이 안된다. @Autowired 필드 명 매칭 @Autowired는 타입 매칭을 시도하고, 이때 여러 빈이 있으면 필드 이름 / 파라미터 이름으로 빈 이름을 추가 매칭한다. 위와 같이 파라미터이름을 보고 같은 타..

생성자도 만들어야 하고, 주입 받은 값을 대입하는 코드도 만들어야 하고 필드주입처럼 좀 편리하게 사용하는 방법은 없을까?? 롬복 라이브러리 적용하기 build.gradle에 설정을 추가해준다. 참고로 처음에 spring프로젝트를 만들때 thymleaf처럼 Dependencies에서 Lombok을 선택하여 세팅할 수도 있음. 처음 만들때 추가하지 않았기 때문에 직접 추가시켜줌. (설정에 들어가서 Enable annotation processing 체크) 롬복의 기능 우리가 원래는 필드에 getter / setter를 만드려면 위와 같이 만들어줘야했지만, 롬복을 사용하면 getter / setter 자동으로 생성해준다. @Getter / @Setter 애노테이션 사용 생성자 관련 애노테이션도 제공하고 굉장히..