본문 바로가기

Programing

(403)
Spring Cloud 2024.0.0 릴리스 Spring Boot 3.4.0이 릴리스할 때 처음 의존하는 Spring Cloud 2024.0.0이 아닌 RC1이었다.[WIL] Spring Boot 3.4.0 - JPA 통합테스트 깨짐 이슈3일전 2024년 12월 2일 2024.0.0이 릴리스되었다.릴리스 노트: https://github.com/spring-cloud/spring-cloud-release/wiki/Spring-Cloud-2024.0-Release-Notes 이제 https://start.spring.io/에서도Spring Cloud 의존이 된 경우 마일스톤용 리포지토리가 불필요하다. 이전:repositories { mavenCentral() maven { url = uri("https://repo.spring.io/mil..
[WIL] Spring Boot 3.4.0 - JPA 통합테스트 깨짐 이슈 스프링 부트를 3.3.5에서 3.4.0으로 올렸다.총 4293개의 테스트 케이스중에 15개의 에러, 1개의 실패가 발생했다. 1개의 실패는 spring-web의 DefaultResponseErrorHandler 코드의 변경으로 이루어졌다.3.3.5 업데이트글과 마찬가지로 getErrorMessage의 메시지 구성이 변경되어 깨지는 것이었다.이슈: https://github.com/spring-projects/spring-framework/pull/28958커밋: https://github.com/spring-projects/spring-framework/commit/f85c4e1ea714281c03287d1448dab9efcf81fc34Spring Cloud의 의존 버전이 2024.0.0가 아닌 202..
[Spring] Boot update 3.3.4 to 3.3.5, MethodArgumentTypeMismatchException 변경 사항 확인 by 테스트 코드 지난 주 스프링 부트 버전 업데이트를 진행했다.스프링 부트 버전 변화에 따라 스프링 프레임워크 버전도 업데이트가 되었다.spring boot 3.3.4: spring framework 6.1.13spring boot 3.3.5: spring framework 6.1.14프레임워크의 기능을 테스트할 때를 알기Zarar의 블로그에 좋은 소프트웨어 개발 습관들(Good software development habits)이라는 글을 본 적이 있다.GeekNews에  "프레임워크의 기능에 대한 테스트를 하지 않기"로 변역이 되어 있어서 무조건 프레임워크의 기능을 테스트하지 말자로 들릴 수 있다. 하지만 나는 "프레임워크의 기능을 테스트할 때와 하지 말 때를 알자"로 해석했다.Know when you're test..
[WIL] 외부 개발자의 참여로 개선을 이루는 오픈소스 사례 - 팝빌 금주에 있었던 재미있던 경험을 블로그에 남겨봅니다. 회사에서는 링크허브(LinkHub)라는 비즈니스 파트너를 통해 문자 메시지 발송 서비스를 이용하고 있었다.Spring Boot 기반의 Kotlin JVM으로 개발을 하고 있었다. 그래서 링크허브에서 Java 언어를 위해 제공하는 SDK를 더 쉽게 연동할 수 있게 제공하는 Spring Boot SDK를 사용하고 있었다.// build.gradle.ktsdependencies { // .. implementation("kr.co.linkhub:popbill-spring-boot-starter:1.4.0")} 위와 같이 의존성을 추가하면 스프링 부트 스타터가 자동 설정을 통해 com.popbill.api.MessageService 인터페이스를 DI가 가능..
[Kotlin] 커버리지 측정 도구를 JaCoCo에서 Kover로 변경하다 그동안 Kotlin을 사용하면서 Java의 도구들을 코틀린 도구들로 변경해서 사용했습니다.JUnit → KotestMockito → MockK회사에서는 SonarQube의 클라우드 버전인 SonarCloud를 사용하여 정적 코드 분석을 사용하고 있었습니다.코드 품질 중 코드 커버리지는 JaCoCo의 XML 테스트 리포트를 이용하여 제공을 하고 있었습니다. 가끔 테스트를 할 수 없는 부분이나 이미 테스트가 완료되었음에도 커버가 안된다는 분석이 나와서 의아함을 느끼고 있었습니다. JaCoCo 오탐들Spring Boot의 애플리케이션을 수행하는 부분 코드를 보면 닫는 괄호 부분도 커버가 안된다고 JaCoCo에서는 표시가 됩니다. 또한 Java에는 없고 Kotlin에만 있는 value class도 어떤 경우는..
[JobRunr] 지연된 작업 기능으로 문자 메시지 상태 조회하기 2022년 8월 진행했던 프로젝트 중에 문자 메시지 발송하는 기능이 있었다.백오피스를 이용하는 직원들은 문자로 고객과 커뮤니케이션을 하는 일이 있었다.자주 사용하는 문구 기능과 더불어 시스템을 통한 메시지 발송 기능으로 시간 비용을 줄일 수 있었다.상태 조회문제는 문자 메시지 발송 후 상태 조회를 하는 방식이었다. 문자 메시지는 서드파티를 통해 수행했는데 1) 폴링 방식과 2) 콜백을 받는 방법 의 크게 두 가지 모두 제공하고 있었다.문자 메시지는 발송 즉시 상태는 곧바로 알 수 없었고 수초 이상 걸릴 수 있었다.따라서 언제 상태가 제대로 되는지는 알 수 없기에 후자 방식이 바람직했다. 하지만 콜백을 받기 위해서는 외부에서 훅(hook)을 줄 수 있는 인터페이스를 준비해야 했다.인프라적인 지원이 필요했는..
[Spring] @Retryable과 @Transactional 는 순서에 따라 동작을 다르게 한다? 금주에 확인한 [Spring] 중첩된 @Transactional의 readOnly 동작 확인 관련해서 인터넷에서 찾아보다가 순서에 대한 글들을 발견했다.[끄적끄적] @Transactional 안에서 retry 사용을 주의하세요 ✔스프링 @Retryable 과 @Transactional의 주석 순서에 따른 프로세스 차이 ❓1번 글은 트랜잭션 안에서 재처리 처리되는 부분이 문제가 될 수 있겠다는 점에서는 동의를 했다.2번 글의 @Retryable과 @Transactional 는 순서에 따라 동작을 다르게 한다는 글을 보고 정말로 그런지 궁금해졌다. 왜냐하면 만약 '내가 프레임워크 개발자라는 관점'으로 생각해보았을 때, 만약 Annotation의 선언 순서에 따라 동작이 달라지도록 구현을 했다면개발자들이 예측..
[Spring] 중첩된 @Transactional의 readOnly 동작 확인 배경이번 주 진행했던 작업 중에 @Transactional(readOnly = true)가 붙은 리포지토리 메서드에서 데이터를 읽지 못하는 현상이 있어서 디버깅을 했다.가설가장 먼저 떠오른 원인은 Writer 인스턴스와 Reader 인스턴스간의 복제 지연(Replication Rag)이었다. 이전 회사에서 복제 지연으로 조회 데이터가 없었던 경험이 있었기 때문이다.당시 주문 도메인을 담당하고 있었다. 주문이 만들어지고 나서 메시지 큐로 이벤트를 보내는 역할이었다. 마침 큐를 소비(consume)하는 클라이언트가 API를 통해 주문 데이터를 조회를 하고 있었다. 문제는 API가 데이터 응답을 할 때 사용하는 DB는 Reader 인스턴스에서 읽도록 구현이 되어 있었다. 당시에는 이런 상황을 위해 Writer..