jhhan의 블로그

오랜만에 다시 써봅니다. (오랜만에 작성하는 블로그여서 저번에 뭘 썼는지도 잊었습니다...) 지난번 포스트에서는 프로토타입과 싱글톤 타입을 함께 쓸 때 나타날 수 있는 문제점에 대해 알아봤는데, 이번에는 이에 대한 해결법을 알아보겠습니다. 일단 지난번에 다뤘던 문제는 싱글톤 빈 생성 싱글톤 빈이 주입받을 때 프로토타입 빈이 주입 그래서 프로토타입 빈이지만 싱글톤 처럼 작동 이런 문제가 있었습니다. 우리는 싱글톤 빈이 있더라도 프로토타입 빈의 성격을 가진 것을 사용하고 싶다는 것이죠. 그럼 가장 단순하게 생각하면 되죠! 바로 → 싱글톤 빈이 프로토타입 빈을 사용할 때마다 스프링 컨테이너에 새로 요청하는 것입니다. @Test void providerTest() { AnnotationConfigApplicat..

이번 포스트에서는 프로토타입과 싱글톤타입이 같이 쓰이는 경우에 대해서 알아보겠습니다. 이전 포스트에서 프로토타입에 대해서 다뤘습니다. 하지만 실무에서는 보통 싱글톤과 프로토타입이 같이 쓰이는 경우가 많다고 합니다. 그러면 아마도 문제가 생길 경우가 있을 것입니다. 그에 대해 알아보겠습니다. 먼저 프로토타입에 대해 한번 복습해봅니다. scope 패키지 밑에 SingletonWithPrototypeTest1.java를 생성합니다. import org.assertj.core.api.Assertions; public class SingletonWithPrototypeTest1 { @Test public void prototypeFind() { AnnotationConfigApplicationContext ac ..

오랜만에 글을 써봅니다. 이번 포스트에서는 빈 스코프에 대해서 알아보겠습니다. 지금까지는 빈 스코프에 대해서 '싱글톤'으로 한정지어서 계속 진행했습니다. (스프링 빈이 기본적으로 싱글톤으로 생성됨) 하지만 빈 스코프는 싱글톤만 있지 않습니다. 일단 종류를 알아보겠습니다. (많이 쓰이는 것들을 알아보겠습니다.) 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작부터 종료까지 유지되는 가장 넓은 범위 프로토타입 : 빈의 생성, 의존관계 주입, 초기화만 하고 그 이후는 관리하지 않음 웹 관련 스코프 request : 웹 요청이 들어오고 나갈 때까지만 유지되는 스코프 session : 웹 세션이 생성되고 종료될 때까지 유지되는 스코프 application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프 이렇..

이전 포스트에서 말한대로 빈 생명주기 콜백을 지원하는 3가지 방식에 대해 알아보겠습니다. 스프링은 크게 3가지 방식으로 빈 생명주기 콜백을 지원합니다. 인터페이스(InitializingBean, DisposableBean) 설정 정보에 직접 추가 애노테이션(@PostConstruct, @PreDestroy) 1. 인터페이스(InitializingBean, DisposableBean) 인터페이스를 이용하는 방식입니다. 먼저 NetworkClient 클래스입니다. public class NetworkClient implements InitializingBean, DisposableBean { private String url; public NetworkClient() { System.out.println("..

이번 포스트에서는 빈 생명주기에 대해 알아보겠습니다. 애플리케이션의 시작 시점 데이터베이스 연결, 외부 연결 등 필요한 연결 관계를 미리 작업 - 초기화 작업 애플리케이션의 종료 시점 연결 관계들을 잘 종료(소멸) 애플리케이션의 시작과 종료에서는 위와 같은 설정이 필요합니다. 이런 설정을 스프링을 통해서 진행하는 것을 해볼 예정입니다. 단순하게 외부와 연결하는 어떤 모듈이 있다고 가정합니다. (여기서는 그냥 String만 이용해서 이렇게 진행될 것이다.. 라고 해보겠습니다.) 위의 구조처럼 lifecycle 패키지 밑에 NetworkClient 클래스와 BeanLifeCycleTest 클래스를 만들어둡니다. public class NetworkClient { /** * 2021.08.16 * BeanLi..

이번에는 스프링 빈의 자동 & 수동 등록에 대해서 다뤄보겠습니다. 이번 포스트 역시 번외입니다. 스프링 빈의 자동, 수동 등록을 어떻게 해야할까에 대한 내용을 다룰 것이고, 이 포스트야말로 정말 크게 중요하지 않을 수 있습니다. 그리고 자동, 수동 등록의 경우 업무 수준에서는 어떻게 동작할 지 회사마다 기준이 있을 겁니다. 그렇기 때문에 가벼운 마음으로 읽어주시면 될 것 같습니다. 요즘 추세는 아무래도 자동 등록을 선호하고 사용하는 것이 트렌드인 것 같습니다. 사실 설정 정보를 바탕으로 명확히 나누는 것이 바람직하지만, 수동 등록의 경우 @Configuration, @Bean, 객체 생성 등의 코드를 일일이 다 적어줘야 합니다. 이 부분은 개발자의 입장에서는 굉장히 번거롭습니다. 그리고 수백개가 될 수도..

이번 포스트는 조회한 빈이 여러개이고, 여러 개인 빈이 모두 필요한 경우에 대해서 살펴보겠습니다. 앞에서는 조회한 빈이 여러개인 경우 그 중에 1개만 선택해서 진행하는 것으로 했습니다. 하지만 어떤 경우에는 조회한 빈이 모두 필요할 때도 있습니다. 전에 사용했던 것을 예시로 들면 DiscountPolicy를 사용했었죠. DiscountPolicy는 fix와 rate으로 나뉘어져 있는데, 이 2개 모두 필요하다고 생각해보면 되겠습니다. (할인을 여러가지 경우로 나누어서 생각하는 것이죠!) 테스트 파일을 만들어서 진행할 것입니다. hello.core.autowired.AllBeanTest 경로가 되도록 진행하겠습니다. public class AllBeanTest { @Test void findAllBean(..

이번 포스트는 그렇게까지 중요한 포스트는 아닙니다. 직접 애노테이션을 만들고 적용해보는 것을 해보려고 합니다. 이전 시간에 조회한 빈이 여러 개인 경우에 대한 해결책에 대해 살펴봤습니다. 그 중에서 @Qualifier에 대해서 알아봤는데요. @Qualifier의 단점이 있습니다. 예시를 한 번 보겠습니다. @Component @Qualifier("mainnDiscountPolicy") public class RateDiscountPolicy implements DiscountPolicy 만약 @Qualifier의 이름을 mainnDiscountPolicy라고 잘못 입력하면 어떻게 될까요? 당연히 에러가 납니다. 하지만 컴파일 시에 에러가 나지 않습니다. 그러면 앱이 구동된 후에 문제가 생겼다는 것을 알게..