Interceptor에서 로그 생성, yml 파일로 별도 저장 설정하기 스프링에서 요청과 응답이 어떻게 처리되었는지 간단하게 기록을 남기고 싶었다. AOP를 사용할 수도 있지만 나는 Interceptor의 preHandle()과 postHandle()를 통해 로그를 남기는 방법을 선택했다. 아래와 같이 interceptor를 만들고 @Configuration이 붙은 파일에서 Interceptor를 추가하였다. public class LoggingInterceptor implements HandlerInterceptor { private final Logger logger = LoggerFactory.getLogger(this.getClass().getSimpleName()); @Override publi..
커넥션 풀 라이브러리를 사용하면 풀에 커넥션을 저장, 재사용이 가능하며 커넥션들의 유효성을 검사하는 등의 기능을 사용할 수 있다. 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 ..
mockito는 스스로를 자바의 단위 테스트를 위한 '맛있는' 프레임워크라고 부르고 있다. mockito를 사용하면 기존 코드, 혹은 아직 만들지 않은 코드에 대한 스텁(Stub)을 만들 수 있다. mockito와 Stub을 통한 테스트가 어떤 장점이 있길래 많은 사람들이 이를 사용하는 것일까? Out-In 개발은 비즈니스 요구 사항이 명확하지 않은 상태에서 빠르게 사용자 인터페이스부터 설계하는 방식이다. 사용자의 진입점을 먼저 정의한 뒤 비즈니스 로직들에 대한 설계가 이루어진다. 내부 구현에 대한 설계가 완벽하게 이루어지지 않아 Out-In 방식으로 사용자의 진입점부터 개발하는 상황을 생각해 보자. 간단하게 하나의 서비스 클래스를 의존하는 컨트롤러를 아래와 같이 만들었다. MockitoService..
스프링에서 사용자의 요청은 필터를 거쳐 DispatcherServlet으로 넘어가고, 내부의 doDispatch() 메서드를 통해 해당 요청에 대한 인터셉터들의 preHandle()이 처리된 후 컨트롤러로 넘어간다. 나의 경우 인터셉터에서 인증 관련 처리를 하기 위해 Authentication 헤더를 읽어 인증과 인가를 수행한다. 이후 ArgumentResolver 혹은 컨트롤러에서 다시 사용자의 이메일 혹은 아이디를 통한 처리를 진행한다. 이때 인터셉터에서 이미 암호화된 Authentication 헤더의 값을 해석하고 파싱 했음에도 값을 캐싱하지 않는다면 이후의 ArgumentResolver에서 다시 해석과 파싱 작업을 해야 한다. 이런 불편을 없애기 위해 컨트롤러 메서드 앞에서 요청이 처리될 때 값을..
DispatcherServlet과 그 내부를 살펴보며 어떤 순서로 요청이 처리되는지, 그리고 어디서 어떻게 최적의 핸들러를 탐색하는지 알아보았다. 내부 구현은 Spring의 버전에 따라 달라지므로 세부 코드보다는 클래스 간 흐름이 어떤 식으로 이루어지는지 보는 것을 추천한다. 설명에 사용된 Spring 버전은 6.0.7이다. DispatcherServlet의 처리 순서 DispatcherServlet 은 우리가 만들어놓은 Handler(컨트롤러), Interceptor, 에 대한 정보를 리스트의 형태로 가지고 있다. ApplicationContext가 완성된 뒤 HandlerMapping 등 각 단계에 필요한 빈 타입을 순차적으로 찾아 등록한다. // org.springframework.web.servl..
Random Port의 SpringBoot 테스트를 진행할 때 Transactional이 적용되지 않는 문제를 직면하여 이유를 간단히 알아보았습니다. 잘못된 내용이 있다면 지적 부탁드립니다. @SpringBootTest의 Web Environment SpringBootTest의 Web Environment 설정은 네 가지가 있다. 기본값인 MOCK은 mocking 된 서블릿(WebApplicationContext)을 로드하며 NONE의 경우는 서블릿 환경을 아예 제공하지 않는다. 반면 RANDOM_PORT 혹은 DEFINED_PORT 옵션을 사용하면 각각 임의의, 혹은 지정된 포트로의 실제 서블릿 환경(EmbeddedWebApplicationContext)을 로드한다. 이로 인해 RANDOM_PORT 혹..
- Total
- Today
- Yesterday
- GitHub Discussion 템플릿
- 람다식
- 의존성 주입
- 스프링
- logback-spring.xml
- MySQL
- JPA JSON
- multiplebagsfetchexception
- invokedynamic
- java switch case
- RandomPort
- 자바
- MySQL 이벤트 스케줄
- 함수형 인터페이스
- 우테코
- springboottest
- Spring
- Fromtail
- GitHub Discussion
- stubbing
- GitHub Discussion Template
- Jenkins 예약 배포
- 생성자 주입
- JPA
- Java
- 우테코 프리코스
- Spring Boot Monitoring
- Spring 테스트
- 우테코 5기
- Payload 암호화
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |