반응형

JAVA/JAVA | Spring 학습기록 72

[Spring] @Configuration vs @Component

스프링은 IoC 컨테이너를 통해 적재적소에 빈 객체를 반환해준다. @Configuration, @Component 어노테이션을 붙여주면 해당 클래스는 스프링 관리 대상이 된다는 점을 보면 크게 차이는 없어보일 수 있다. 어떠한 상황에 @Configuration을 쓰고 어떠한 상황에 @Component를 쓰는 것이 좋을까? 1. @Configuration은 @Component를 포함하고 있다 둘의 차이점을 비교하기 전에, @Configuration이 @Component를 포함하고 있다는 것을 확인하자. 그렇기 때문에 @Configuration 어노테이션이 붙여진 클래스도 @Component 어노테이션이 붙여진 클래스처럼 스프링 컨테이너 관리 대상이다. 참고로 @Component는 아래와 같이 소개돼있다. ..

[Spring] REQUIRED, REQUIRES_NEW 옵션과 Try-Catch

스프링에서 트랜잭션을 다루다보면 두 개 이상의 트랜잭션이 서로 합류하는 경우가 존재한다. 이 때, @Transactional의 전파레벨을 적절히 조정하는 것이 중요하다. 스프링 전파레벨에 대한 이해가 부족하다면 아래 글을 읽고 오는 것을 추천한다. 스프링 @Transactional 전파레벨: https://kth990303.tistory.com/385 @Transactional REQUIRES_NEW 롤백 상황: https://kth990303.tistory.com/387 지난 포스팅(387번)에서는 REQUIRES_NEW 전파레벨 옵션일 때 @TransactionalEventListener를 이용하여 자식이 롤백되더라도 부모가 롤백되지 않도록 설정해주었다. 이번 포스팅에서는 try-catch에 대해 살..

[Spring] REQUIRES_NEW 옵션만으론 자식이 롤백될 때 부모도 롤백된다

두 개 이상의 트랜잭션이 합류할 경우, 트랜잭션 전파레벨 옵션 설정으로 트랜잭션을 관리할 수 있다. 특히, 트랜잭션 전파레벨 중 REQUIRED, REQUIRES_NEW는 실제로도 꽤나 자주 쓰이는 옵션이라 알아두면 더더욱 좋다. 전파레벨 옵션에 대해 궁금하다면 아래 글을 살펴보자. https://kth990303.tistory.com/385 [Spring] @Transactional의 전파 레벨에 대해 알아보자 스프링에선 진행중인 트랜잭션에서 다른 트랜잭션이 참여할 때의 합류조건을 설정할 수 있는 Propagation 옵션이 존재한다. DB에서 자체적으로 제공해주는 트랜잭션 격리레벨과 다르게 전파레벨은 kth990303.tistory.com 이번 포스팅에서는 REQUIRES_NEW 전파레벨 옵션에 대해..

[Spring] @Transactional의 전파 레벨에 대해 알아보자

스프링에선 진행중인 트랜잭션에서 다른 트랜잭션이 참여할 때의 합류조건을 설정할 수 있는 Propagation 옵션이 존재한다. DB에서 자체적으로 제공해주는 트랜잭션 격리레벨과 다르게 전파레벨은 스프링에서 개발자들의 편의를 위해 제공해주는 기능이다. 특히, 트랜잭션 격리 레벨과 마찬가지로 전파레벨은 cs 면접에서 자주 물어보는 주제이기도 하므로 잘 학습해두는 것이 좋을 듯하다. 이번 포스팅에선 트랜잭션 전파 레벨에 대해 작성해보도록 하겠다. 트랜잭션 전파 레벨은 총 7가지 트랜잭션 전파레벨에는 총 7가지 종류가 있다. 스프링 문서에 적혀있는 내용을 바탕으로 한 번 살펴보자. REQUIRED: Support a current transaction, create a new one if none exists...

[Spring] @SpringBootTest의 webEnvironment와 @Transactional

우리는 @SpringBootTest 어노테이션을 이용하여 손쉽게 통합테스트를 진행할 수 있다. 하지만 @SpringBootTest의 webEnvironment 설정에 따라 테스트 격리가 잘 되지 않는 현상을 발견할 수 있다. 왜 그런 것일까? @SpringBootTest의 webEnvironment @SpringBootTest를 파고 들어가면 아래와 같이 webEnvironment 세팅을 볼 수 있다. 기본값은 MOCK이다. WebApplicationContext를 로드하지만, 내장된 서블릿 컨테이너가 아닌 MOCK 서블릿을 제공한다. 실제 서블릿 환경에서 테스트를 진행해보고 싶다면 RANDOM_PORT나 DEFINED_PORT로 진행해주어야 한다. RANDOM_PORT랑 DEFINED_PORT는 위 사..

[Spring] @MockBean VS @SpyBean

Spring Boot 환경에서 여러 협력 객체들이 존재하는 통합테스트는 빈을 호출하기 위해 @SpringBootTest를 사용하는 경우가 많다. 그리고 협력 객체들이 많을 때에는 테스트를 위한 기대 행위 전처리 작업을 mockito를 이용하여 stub을 통해 test double을 만들어주는 경우들이 존재한다. @SpringBootTest와 함께 사용한다면 @Mock, @InjectMocks 대신 @MockBean을 주로 사용할 것이다. 그런데 테스트 코드를 작성하는 방법에 대해 공부하던 도중 @SpyBean이라는 어노테이션을 알게 됐다. 이 어노테이션은 뭐하는 애일까? 그리고 어떻게 사용하는게 좋을까? @MockBean 개인적으로 나는 웬만해선 @MockBean 대신 실제 객체를 사용하는 방식을 사용하..

[Spring] log4j2를 활용한 로깅 전략을 다룬 yml 파일을 생성하자

배포 환경에서, 그리고 개발하면서 api를 맞춰보면서 특정 문제가 발생했을 때 그에 대한 기록을 남겨두면 이후에 그 기록을 바탕으로 대처를 할 수 있다. Spring에서는 다양한 logging configurations들을 제공한다. log4j, logback, log4j2들이 대표적이다. 이번 포스팅에선 log4j2를 선택한 이유와, 개발 및 배포환경에서 각각 다른 log4j2 yml을 어떻게 만들었는지 작성해보도록 하겠다. logback vs log4j2 log4j는 2015년에 서비스가 종료됐고, 오래된 로그 프레임워크이기 때문에 제외하도록 하겠다. logback log4j 개발팀이 제작하여 기본적으로 log4j와 비슷하지만 성능이 향상됨. spring-boot-starter-web의 기본 로깅 프..

[JAVA] IoC, DI, DIP

친구와 얘기하던 중, Spring IoC, DIP 개념에 대한 얘기가 나왔다. 이 개념들은 구글링하면 워낙 잘 정리된 글들이 많아 별도로 작성하지 말까 고민도 했다. 하지만 해당 개념들은 객체지향에서 매우 중요하기 때문에 한번쯤은 포스팅하는 것이 좋을 듯하여 정리해보려 한다. IoC(제어의 역전) Inversion of Control, 즉 IoC는 제어의 역전이라고 번역된다. 쉽게 말하자면 어떤 객체에 대한 관리를 나 대신 다른 애한테 맡긴다는 것이다. 스프링을 쓴다면 스프링에게 특정 객체의 생성과 소멸을 빈으로 등록해 맡겨주는 것으로 생각하면 된다. 즉, 제어권을 내가 아닌 스프링 컨테이너에게 빈의 생성, 의존 관계 설정을 맡기는 것이므로 IoC가 이루어지는 것이다. 스프링을 사용하지 않는다고 하더라도..

[Spring] 인증 토큰을 생성하는 JwtTokenProvider를 알아보고 테스트를 작성해보자

그동안 미루고 미루어왔던 JwtTokenProvider에 대해 알아보고, 테스트 코드를 작성하는 법을 작성하려 한다. JwtTokenProvider는 로그인 인증 과정을 처리할 때 반드시 필요한 access Token을 생성해주는 역할을 한다. 이 JwtTokenProvider는 @Configuration 어노테이션으로 스프링 빈으로 관리되고 있는 ArgumentResolver이나 Interceptor에서 사용되고 있기 때문에 @Component 어노테이션으로 스프링 빈 등록을 해주어야 한다. 특히 인터셉터에서 HttpServletRequest로 토큰을 추출해주고, 아규먼트 리졸버에서 토큰값으로 payload를 가져오는 역할을 해주기 때문에 JwtTokenProvider의 역할은 매우 중요하다. JwtT..

[Spring] 테스트에서 test 스키마가 아닌 main의 스키마를 의존한다면? _ application.yml 설정

아래 그림과 같이 main과 test 패키지에서 따로 db를 생성해야 한다고 해보자. 테스트에서는 매번 drop table if exists를 해주지만, main에서의 schema.sql에서 drop table을 해줄 경우에 배포할 때마다 데이터들이 리셋되므로 정말 큰일나게 된다. 이렇게 테스트 때와 실제 실행에서의 schema.sql을 다르게 해주고 싶다면 어떻게 해야 할까? @Sql 어노테이션을 쓰는 방법으로 해결된다고들 하지만, 나는 그 방법으로 해결되지 않았다. test 클래스마다 @Sql 어노테이션으로 classpath prefix까지 붙여주면서 사용해보아도 자꾸 test_schema가 아닌 메인 패키지의 schema.sql을 의존했다. 아직도 이 부분은 명확한 이유를 모르겠다.. 그럼 어떻게 ..

반응형