스프링의 ApplicationRunner를 활용해 보자.📌 서론스프링 부트(Spring Boot) 애플리케이션에서 ApplicationRunner를 사용하면 애플리케이션이 시작될 때 특정 로직을 실행할 수 있다. 특히 @Configuration 클래스 내에서 @Bean으로 등록하면 필요한 빈들을 주입받아 유연하게 사용할 수 있다. 이번 포스팅에서는 실무에서 바로 적용할 수 있는 몇 가지 예제와 함께 ApplicationRunner의 활용 방법을 자세히 알아보도록 하자. 1. ApplicationRunner란 무엇인가?ApplicationRunner는 스프링 부트 애플리케이션(서버)이 완전히 초기화된 후 실행되는 콜백 인터페이스다. 이를 구현하면 애플리케이션 시작 시점에 필요한 작업을 수행할 수 있다. ..

스프링의 빈 스코프를 알아보자📌 서론스프링으로 개발을 하다 보면 스프링 빈을 정말 많이 사용하게 된다. 요즘은 "모 개발자(영한쌤)의 강의"를 잘 듣는다면 스프링 빈에 대한 개념을 정말 잘 배울 수 있다고 생각한다. 나도 영한쌤의 강의를 들어가며 성장했고 덕분에 스프링에 대해 단단하게 기초를 잡고 현업에 적응할 수 있었다. 이렇게 무럭무럭 성장하는 주니어 시절을 보내던 와중 스프링의 빈 등록 원리를 더 자세히 알고 싶다는 생각이 들어 겁도 없이 공식 가이드 자료를 살펴보기 시작했다.나는 가끔 스프링의 공식 업데이트 내용을 보고 싶어서 가이드 정보를 구경하러 들어갔기에 처음 확인한 것은 아니지만 이 정도로 자세히 살펴본 적은 없었다. 이번에 가이드를 자세히 읽으면서 계속해서 놀랐다. 왜냐하면 영어로 되어..

스프링의 순환참조 상황을 알아보자📌 서론스프링으로 개발을 하다 보면 정말 가끔씩 발생하는 오류가 있다. 바로 circular references (순환참조)다.스프링 빈을 등록하면서 2가지의 클래스가 서로를 의존하면 이러한 문제가 발생한다. 서버가 실행되면 스프링 컨테이너가 빈을 등록하는 과정에서 의존성 주입을 하는데 이 과정에서 서로 의존하는 두 빈이 서로를 기다리며 무한루프에 빠지게 되는 것이다.순환참조라는 이름만 봐도 순환해서 참조한다는 의미이므로 생각해 보면 간단하게 한쪽의 참조만 끊어주면 해결될 것으로 보인다. 그러나 가끔은 서로의 로직을 사용해야 하는 경우가 있을 수도 있다. 이때는 어떻게 문제를 해결해야 할까?  이런 상황에 문제를 해결하는 여러 가지 방법이 존재한다. 1. @Lazy 어노..

코틀린 스프링에서 Spring Validation을 적용하기 위해서는 꼭 알아둬야 할 것이 있다.📌 서론코틀린 스프링으로 개발하던 도중 독특한 문제를 만났다.프로젝트에 spring validation을 적용시켜 requestDto의 유효성을 검증하도록 설계했다. 왜냐하면 코틀린이 null safe 한 언어라지만 클라이언트 측에서 보내는 데이터까지 모두 컨트롤할 수 없기 때문에 클라이언트 요청을 바로 validation으로 검증하여 데이터의 무결성을 보장하고자 했다.  그래서 나는 검증하고자 하는 DTO 필드에 @NotBlank 어노테이션을 적어줬고 HTTPie(Postman)을 사용해 validation을 적용한 필드에 값을 넣지 않고 api요청을 보내봤다. (일부로 오류를 발생시키기 위함) 근데.....

Spring Event 스레드의 동작원리를 이해해 보자 📌 서론 스프링 이벤트(Application Events)는 기본적으로 발행자(publisher)와 리스너(listener)가 같은 스레드에서 동작한다. 즉, 이벤트를 발행하는 메서드를 호출하면 그 호출을 처리하는 스레드가 이벤트 리스너도 처리하는 것이 기본 동작이다. 이번 포스트에서는 스프링 이벤트와 스레드의 동작 방식을 자세히 알아보자 1. 스프링 이벤트와 스레드 동작 방식 (1개의 이벤트 리스너) 스프링 이벤트의 스레드 동작(동기) 기본적으로, 스프링에서 이벤트를 발행하면, 그 이벤트는 기존 로직을 처리하고 있던 같은 스레드에서 처리된다. 예를 들어 어떤 컨트롤러 메서드에서 이벤트를 발행했다면, 그 이벤트에 대한 처리도 요청을 처리하고 있던 그..

커스텀 어노테이션 적용기 📌 서론 SpringBoot로 개발하다 보면 @Controller, @Service, @Repository, @Transactional, @Component, @Bean 등등 정말 많은 어노테이션을 사용하여 편하게 개발을 한다. 근데 스프링이 제공하는 어노테이션 말고도 개발자가 직접 본인만의 어노테이션을 만들어서 프로젝트에 적용시킬 수 있다는 것을 아는가? 아마 대부분의 개발자들은 알고 있었겠지만 사용해 볼 일은 거의 없었을 것이다. 나는 사용자 커스텀 어노테이션이 어떻게 작성되고 프로젝트에서 사용되는지 내부의 동작원리가 궁금했고 직접 만들어보기로 했다. 지금부터 Spring에 직접 커스텀 어노테이션을 만들어보면서 이게 어떻게 동작하는지 알아보자. 완성된 코드는 아래의 Repo..

스프링은 어떻게 트랜잭션 전파를 처리하는지 알아보자 📌 서론 스프링 프레임워크에서 @Transactional 애노테이션을 사용할 때, 기본적인 전파 수준(propagation level)은 Propagation.REQUIRED다. 이 전파 수준은 현재 진행 중인 트랜잭션이 있으면 해당 트랜잭션에 참여하고, 없으면 새로운 트랜잭션을 시작하는 것이다. 즉, 메서드가 트랜잭션 내에서 실행되도록 보장해 준다. 그런데 이렇게만 알고 넘기기엔 답답한 마음이 들었다. 스프링은 내부에서 어떻게 이 전파 수준을 추출하고 해석해서 동작시키는지 정말 궁금했고 그 내용을 공부했다. 이번 포스트를 통해 그 내용을 공유한다. 이번 포스트는 정말 헷갈리고 어려울 수 있다. 쉽게 이해하기 위해 직접 코드를 따라가 보는 것이 좋다고 ..

@ModelAttribute에서 데이터 바인딩을 위해서 꼭 필요한 메서드가 존재한다. 📌 서론 컨트롤러에서 매게 변수로 dto객체를 받을 때 발생하는 바인딩 오류는 정말 간단하게 해결되지만 자주 발생하는 오류이기도 하다. 그만큼 바인딩에 대해서는 신경 쓰지 않고 알아서 적용되겠지?라는 생각을 가지고 어노테이션을 사용하게 되기 때문인데 수많은 api를 만들어 보게 되지만 바인딩도 @RequestBody인지 @ModelAttribute인지에 따라 그 방식이 다르다. 이번에는 @ModelAttribute를 사용했을 때 나의 실수로 인해 바인딩에 실패했던 내용을 소개하고자 한다. 1. 오류가 발생한 상황 오류가 발생한 코드 분석 아래의 API에 요청을 보냈을 때 바인딩 오류가 발생했다. /** * 마이페이지 수..