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

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

스프링에서는 빈 등록 과정이 어떻게 발전되어 왔을까?📌 서론Spring Framework에서의 빈(bean) 설정 방식은 시간이 지나면서 점차 발전해 왔다.초기에는 XML 기반 설정이 주로 사용되었으나, 자바 기반 설정이 도입되면서 설정 관리가 더욱 간편해졌다.이후, 컴포넌트 기반 설정이 등장하면서 빈 관리의 자동화와 모듈화가 크게 개선되었다. 이번 글에서는 이러한 빈 설정 방식의 발전 과정을 예시와 함께 단계별로 알아보자. 참고로 저는 구버전의 springFramework로 개발할 일이 있었는데 xml로 빈 등록하는 과정은 생각보다 복잡했습니다. ㅠㅠ 그래서 이렇게 발전된 것이 너무나도 감사합니다. 1. XML 기반 설정초기 스프링의 빈 설정 방식Spring Framework의 초기 버전에서는 애플..

스프링의 순환참조 상황을 알아보자📌 서론스프링으로 개발을 하다 보면 정말 가끔씩 발생하는 오류가 있다. 바로 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다. 이 전파 수준은 현재 진행 중인 트랜잭션이 있으면 해당 트랜잭션에 참여하고, 없으면 새로운 트랜잭션을 시작하는 것이다. 즉, 메서드가 트랜잭션 내에서 실행되도록 보장해 준다. 그런데 이렇게만 알고 넘기기엔 답답한 마음이 들었다. 스프링은 내부에서 어떻게 이 전파 수준을 추출하고 해석해서 동작시키는지 정말 궁금했고 그 내용을 공부했다. 이번 포스트를 통해 그 내용을 공유한다. 이번 포스트는 정말 헷갈리고 어려울 수 있다. 쉽게 이해하기 위해 직접 코드를 따라가 보는 것이 좋다고 ..