![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/bitmpy/btsgMcXHJ3S/igWQRv2q1cl2xWobakfkUK/img.png)
커넥션 풀 라이브러리를 사용하면 풀에 커넥션을 저장, 재사용이 가능하며 커넥션들의 유효성을 검사하는 등의 기능을 사용할 수 있다. HikariCP는 자바에서 가장 많이 쓰이는 커넥션 풀 라이브러리다. Spring Boot 2.0 이전에는 Apache Commons DBCP(DataBase Connection Pool)이 사용되었으나 2.0부터는 HikariCP를 공식적으로 사용하면서 별도의 설정 없이도 사용할 수 있게 되었다. 기본 설정도 우수하지만 아래와 같이 필요에 따라 설정을 변경할 수 있다. 다음은 hikari datasource 설정에 대한 한 예시이다. # application.yml spring: datasource: url: jdbc:mysql://localhost:3306/example ..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/HoHPf/btsfcN7Mu0h/rtz6fTiAYk1kifhSetpLMK/img.png)
mockito는 스스로를 자바의 단위 테스트를 위한 '맛있는' 프레임워크라고 부르고 있다. mockito를 사용하면 기존 코드, 혹은 아직 만들지 않은 코드에 대한 스텁(Stub)을 만들 수 있다. mockito와 Stub을 통한 테스트가 어떤 장점이 있길래 많은 사람들이 이를 사용하는 것일까? Out-In 개발은 비즈니스 요구 사항이 명확하지 않은 상태에서 빠르게 사용자 인터페이스부터 설계하는 방식이다. 사용자의 진입점을 먼저 정의한 뒤 비즈니스 로직들에 대한 설계가 이루어진다. 내부 구현에 대한 설계가 완벽하게 이루어지지 않아 Out-In 방식으로 사용자의 진입점부터 개발하는 상황을 생각해 보자. 간단하게 하나의 서비스 클래스를 의존하는 컨트롤러를 아래와 같이 만들었다. MockitoService..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/bJlDhq/btserNsd0Tj/VtzFQgYTL3K2ekOkk5l3d0/img.png)
스프링에서 사용자의 요청은 필터를 거쳐 DispatcherServlet으로 넘어가고, 내부의 doDispatch() 메서드를 통해 해당 요청에 대한 인터셉터들의 preHandle()이 처리된 후 컨트롤러로 넘어간다. 나의 경우 인터셉터에서 인증 관련 처리를 하기 위해 Authentication 헤더를 읽어 인증과 인가를 수행한다. 이후 ArgumentResolver 혹은 컨트롤러에서 다시 사용자의 이메일 혹은 아이디를 통한 처리를 진행한다. 이때 인터셉터에서 이미 암호화된 Authentication 헤더의 값을 해석하고 파싱 했음에도 값을 캐싱하지 않는다면 이후의 ArgumentResolver에서 다시 해석과 파싱 작업을 해야 한다. 이런 불편을 없애기 위해 컨트롤러 메서드 앞에서 요청이 처리될 때 값을..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/cvw0Sg/btsec9IWV0S/VMTOMSubcThKKGmbEJPRL0/img.png)
DispatcherServlet과 그 내부를 살펴보며 어떤 순서로 요청이 처리되는지, 그리고 어디서 어떻게 최적의 핸들러를 탐색하는지 알아보았다. 내부 구현은 Spring의 버전에 따라 달라지므로 세부 코드보다는 클래스 간 흐름이 어떤 식으로 이루어지는지 보는 것을 추천한다. 설명에 사용된 Spring 버전은 6.0.7이다. DispatcherServlet의 처리 순서 DispatcherServlet 은 우리가 만들어놓은 Handler(컨트롤러), Interceptor, 에 대한 정보를 리스트의 형태로 가지고 있다. ApplicationContext가 완성된 뒤 HandlerMapping 등 각 단계에 필요한 빈 타입을 순차적으로 찾아 등록한다. // org.springframework.web.servl..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/cNv9st/btscYOgdcU1/cPV7o6rXDGAshOoKLgvtKK/img.png)
Random Port의 SpringBoot 테스트를 진행할 때 Transactional이 적용되지 않는 문제를 직면하여 이유를 간단히 알아보았습니다. 잘못된 내용이 있다면 지적 부탁드립니다. @SpringBootTest의 Web Environment SpringBootTest의 Web Environment 설정은 네 가지가 있다. 기본값인 MOCK은 mocking 된 서블릿(WebApplicationContext)을 로드하며 NONE의 경우는 서블릿 환경을 아예 제공하지 않는다. 반면 RANDOM_PORT 혹은 DEFINED_PORT 옵션을 사용하면 각각 임의의, 혹은 지정된 포트로의 실제 서블릿 환경(EmbeddedWebApplicationContext)을 로드한다. 이로 인해 RANDOM_PORT 혹..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/yoGTv/btsbmfSW0bd/4lcBEAJWRuxdr25Iogcqa1/img.png)
필드 주입도 순환 참조를 검사해 준다? 스프링의 의존성 주입과 관련하여 코드를 작성해 보던 중, 필드 주입 또한 순환 참조를 검사해 주는 것을 확인하여 의문이 생겼다. 기존에 생성자 주입을 권장하는 이유는 빈의 생명주기 중 처음 두 단계 중 1번의 인스턴스 생성을 위한 생성자 호출에서 바로 의존성을 주입해야 하므로 순환 참조를 찾을 수밖에 없기 때문으로 이해했다. 빈 객체의 인스턴스 생성 단계 의존성 주입 단계 @PostConstruct나 InitializingBean 인터페이스의 구현 메서드에 의한 초기화 단계 스프링 컨테이너 종료 시 @PreDistroy나 DisposableBean 인터페이스의 구현 메서드에 의한 소멸 단계 이번에 새로 경험한 것은 생성자 주입이 아닌 필드 주입과 같은 방법으로 빈을..
- Total
- Today
- Yesterday
- 함수형 인터페이스
- 우테코 프리코스
- comparing
- thenComparing
- Spring Boot Monitoring
- GitHub Discussion
- Spring 테스트
- 생성자 주입
- stubbing
- RandomPort
- Java
- 의존성 주입
- 자바
- java switch case
- Fromtail
- JPA
- GitHub Discussion 템플릿
- GitHub Discussion Template
- logback-spring.xml
- JPA JSON
- 스프링
- Jenkins 예약 배포
- MySQL 이벤트 스케줄
- Payload 암호화
- invokedynamic
- 우테코 5기
- springboottest
- Spring
- 우테코
- 람다식
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 |