늘

스프링의 application context는 Application Event를 제공해준다. 해당 이벤트를 사용할 때 기존 트랜잭션에서 커밋이 된 후에 이벤트를 처리할 때, Transaction의 Propagation을 Requires_new 나 @Asnyc로 주지 않으면 같은 트랜잭션으로 묶여서 정상적으로 이벤트가 발급되지 않는다. 따라서 이벤트에 Propagation.REQUIRES_NEW 옵션을 주어서 사용했는데 이때 Requires_new를 사용한다고 해도 상위 트랜잭션에서 예외를 잡아주지 않으면 예외가 전파되어서 상위 트랜잭션도 롤백이 된다. 따라서 try-catch로 잡아줘야 한다. 그런데.. 실제 event에 대해서 예외 테스트를 진행해줬는데 try-catch로 잡지 않아도 예외가 전파되지 ..

스프링과 JPA로 애플리케이션을 개발하다 보면 프록시에 대해서 많이 만나게 된다. 이와 관련되어 구글링을 해보면 게시글들마다 다른 말을 해서 직접 정리해보려고 한다. - 총정리 스프링 AOP는 [런타임에 프록시 인스턴스가 동적으로 변경되는] 다이나믹 프록시 기법으로 구현되어있다 인터페이스의 유무에 따라 다음과 같이 나뉜다. 1. JDK 다이나믹 프록시 2. CGLIB JDK Dynamic Proxy JDK에서 지원하는 프록시 생성 방법 Invocation Handler를 재정의한 invoke를 구현하여 부가기능 수행 Reflection API 사용 인터페이스를 통해서만 프록시 생성 가능 CodeGenratorLibrary(CGLIB) 상속을 기반으로 프록시 생성 final이 붙으면 오버라이딩이 불가능하므..

Spring REST Docs는 테스트가 통과해야 문서화가 된다. API문서 자동화에는 대표적으로 swagger와 Rest docs가 있는데 개인적으로 RestDocs를 선호한다. 장점 Spring REST Docs는 테스트가 성공하지 않으면 문서를 만들 수 없습니다. 즉, 반 강제로 테스트를 해야 하고 이를 통해 신뢰도 높은 api문서가 나온다. 실제 코드에 추가되는 코드가 없습니다. - swagger를 보면 프로덕션 코드에 어노테이션이 덕지덕지 붙어있는데, 이는 관심사의 분리가 실패된 케이스가 아닌가.. 라는 생각이 들어서 RestDocs를 선호한다. 커스터마이징 가능 문서화에 사용할 테스트 도구 여기서 API문서화 할때는 Controller테스트를 통해서 생성하므로 RestAssured보다는 Moc..

@Mock @ExtendWith(MockitoExtension.class)를 클래스 위에 붙여준다. @ExtendWith(MockitoExtension.class) public class MockTests { @Mock private OrderRepository orderRepository; @InjectMocks private OrderService orderService; } @InjectMocks를 사용하면 @Mock으로 만들어진 인스턴스들을 자동으로 주입해준다. (위 예시에서는 OrderService가 OrderRepository를 주입받는 클래스 존재) @MockBean @SpringBootTest public class MockTests { @MockBean private OrderReposi..

빈이 생성된 이후 추가로 호출되는 콜백들이 있는데요. Spring bean lifecycle, Spring bean hook 같은 키워드로 검색해보시면 도움이 될 것 같아요! 저번에 테스트 격리에 대해 학습하면서 토미가 키워드를 주셨는데, 오늘은 이 키워드를 정리해보려고 한다. 빈 생성 IoC컨테이너가 만들어진다. -> ComponentScan을 통해 빈으로 등록할 객체들을 찾는다. IoC 컨테이너 안에 빈을 등록한다. 그리고 의존관계 주입을 하기 전에 준비 단계가 있다. 이 준비 단계에서 객체 생성이 일어난다. 생성자 주입: 객체의 생성, 의존관계 주입이 동시에 일어남 setter, Field 주입: 객체의 생성 -> 의존관계 주입으로 라이프 사이클이 나누어져 있음 스프링 의존관계 주입이 완료된 시점 ..

ResponseEntity의 body에 객체를 넣고 보내주면 json형식으로 주고받아진다. @Controller public class HelloController { @GetMapping(path = "/hello") public ResponseEntity hello() { MoveDto moveDto = new MoveDto("start", "finish"); return ResponseEntity.ok(moveDto); } } @Controller를 통해서 Json이 반환되는 현상이 발생했습니다.. 흔히들 알기론 controller는 데이터를 Model에 담고 반환할 view를 찾는 방식이고 restController는 단순히 json형식의 데이터만 주고받는 것으로 알고 있습니다. 그리고 RestC..

@RequestBody @RequestBody 애너테이션의 역할은 클라이언트가 보내는 HTTP 요청 본문(JSON 및 XML 등)을 Java 오브젝트로 변환하는 것이다. 기본 생성자만을 가지고 json값을 Java객체로 변환해준다. MappingJackson2HttpMessageConverter 내부의 ObjectMapper를 통해 json값을 Java객체로 역직렬화를 한다. 직렬화가 가능한 클래스들은 기본 생성자가 항상 필수입니다. 즉, ObjectMapper를 통해 역직렬화가 이루어지므로 기본 생성자가 필수라는 말이다! 그렇다면 기본 생성자만을 보고 어떻게 필드를 알고 매핑을 해주는 것일까? Jackson ObjectMapper는 Java 오브젝트의 필드에 맵핑할 때 getter혹은 setter매서드..

평소에 runtimeOnly는 런타임 때 작동하겠지, implementation은 gradle이 돌아갈 때부터 작동하겠지라고 대충 생각하고 넘겨와서 그런지 막상 퀴즈를 받으니 대답을 못하겠다.. 이번 기회에 공부하고 정리해보려고 한다. 일단 gradle에 의존성부터 확인해 보았다. 일단 눈에 띄었던 것은 빨간 박스로 표시한 것처럼 runtimeClasspath에 implementation으로 선언된 의존성 파일들이 들어있었다. 대충 implementation은 시작부터 runtime때까지 의존성이 살아있는구나(?)라고 생각했다. CompileClasspath 에러 없이 컴파일을 하기 위해 필요한 클래스와 jar들의 위치를 나타낸다. compileClasspath만 잘 설정했다고 애플리케이션이 잘 작동하는..

계층형 아키텍처(Layered Architecture) or 멀티 티어(tier) 아키텍처 - 책임과 성격이 다른 것을 크게 그룹으로 만들어 분리해두는 것 - 유사한 관심사들을 layer로 나눠서 수직적으로 배열한 것 보통 웹 기반의 엔터프라이즈 애플리케이션은 3개의 계층을 갖는다고 해서 3계층 애플리케이션이라고도 한다. 3계층 아키텍처와 수직 계층(토비의 스프링) Presentation Layer: 웹 기반의 UI를 만들어내고 그 흐름을 관리하는 계층 Service Layer: 비즈니스 로직을 담고 있는 계층 DataAccess Layer: 백엔드의 DB나 레거시 시스템과 연동하는 인터페이스 역할을 하는 계층(infrastructure 계층) 3계층 아키텍처(조영호 개발자님) Presentation: ..

왜 스프링은 싱글톤으로 Bean을 만드는가? 스프링은 was 시작과 동시에 Ioc컨테이너에 빈을 생성하고 관리한다. 따라서 서버의 성능을 좋게 하기 위해서 싱글톤 방식을 취한다. 싱글톤 방식을 사용하지 않는다면 매번 Bean을 생성해야 하므로 성능이 안 좋다. 하지만 싱글톤을 사용하면 한 번에 Bean을 여러 개 만들어서 요청이 들어올 때마다 사용하면 되기 때문에 성능이 좋아진다. 저번 게시물에 디자인 패턴에서 싱글톤 패턴을 학습해서 정리했었다. 그런데 이번 스프링 컨테이너의 싱글톤을 공부하면서 같은 싱글톤이라고 생각했는데 스프링의 싱글톤 레지스트리와 자바의 싱글톤 패턴은 다르다고 한다! 싱글톤 레지스트리는 자바의 싱글톤 패턴의 단점을 보완한 것이라고 한다. 자바의 싱글톤패턴의 단점은 아래와 같다. pr..