우리집앞마당

spring boot 2 기반 애플리케이션을 spring boot 3 로 올리면서 겪은 이슈들에 대해 정리하고자 한다. 기본적인 방법은 공식 마이그레이션 가이드( https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide )를 참고하면 되는데, 문서에 나와있지 않거나 나와있지만 까다로운 부분들을 중점으로 다뤄보고자한다. spring framework 6(boot 가 아니다)부터 ListenableFuture 인터페이스가 deprecate 되었다. 인터페이스가 deprecate 되면서 자연히 그 구현체들도 모두 deprecate 되어 퇴출수순을 밟고있다. 다른 대체 인터페이스를 제공하는 것은 아니며 기존 JDK 에서..

spring data jpa 를 이용하면 repository 의 save() 메서드를 이용해서 엔티티를 저장한다. 이때 save() 메서드는 저장된 엔티티 객체를 반환하는데, 사실 파라미터로 전달된 엔티티 객체의 상태를 변경하고 그걸 그대로 반환하는거라 파라미터로 전달된 객체와 반환되는 객체가 같다. @Test void 동일한_객체를_반환한다() { var person = new Person("lichking"); var savedPerson = personRepository.save(person); assertThat(person).isEqualTo(savedPerson); } 이런 이유로 따로 equals 를 오버라이딩하지 않은 상태에서 Person 객체를 비교하면 테스트가 통과한다. spring d..

spring-boot-starter-web 을 이용해 웹서버 애플리케이션을 만들고 있다면 json 에 대한 핸들링은 jackson 을 이용하게 된다. 물론 jackson 외 다른 라이브러리를 이용하고 싶다면 변경할 수 있다. jackson 에서 실질적으로 json serialize/deserialize 를 담당하는 객체는 ObjectMapper 인데 스프링 부트로 애플리케이션을 만들어봤다면 별다른 설정을 하지 않아도 잘 돌아가는걸 확인할 수 있을 것이다. # custom serializer/deserializer 가 필요한 경우 널리 사용되는 타입들에 대해서는 대부분 정상적으로 serialize/deserialize 가 되기 때문에 고민할 거리가 없다. 하지만 개발자가 임의로 정의한 타입에 대해 원하는 ..

JPA 를 이용하면 엔티티의 상태를 변경해주는 것만으로 update 쿼리를 실행시키게 된다. 이때 발생하는 쿼리는 모든 컬럼을 대상으로 update 를 실행한다. @Entity @Table(name = "person") public class Person { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "person_id") private Long id; @Column(name = "person_name") private String name; @Column(name = "person_age") private int age; // 생성자 생략 public void setAge(int age) { this.age = age;..

모두다 등장한지 오래된 개념들이지만 몇년 전부터 DDD 의 바람이 부는듯 하더니 요즘엔 클린 아키텍처, 헥사고날 아키텍처 등에 대한 관심이 많은 것 같다. 관심이 많은 것과 잘 하는건 분명 다르지만 잘하기 위해서는 일단 관심을 가져야하기에 마냥 나쁘게만 볼 현상은 아니라고 생각한다. 나도 관심을 갖고있는 사람 중 하나인데, 이런저런 이름으로 소통되고 있지만 이들이 주장하는건 결국 도메인에서 기술을 분리하는 것이다. 애초에 spring 프레임워크가 등장했던 것 자체가 POJO 를 지키기 위함이었는데 언젠가부터 우리의 도메인엔 spring 이 침투하고 있다. 이런 내용들을 책이나 자료를 통해 공부하고, 구두로 의견을 나누는건 어렵지 않은데 막상 현업에서 하려고하면 다양한 고민거리들을 마주하게 된다. - 정말..

이전에 builder pattern 에 대한 생각을 포스팅한 적이 있다. 이번엔 무심코 많이 작성하는 ~ByParameter 에 대해 얘기해보고자 한다. 개발자가 가장 많은 시간을 보내는 것은 코드 고민, 코드 작성보다 네이밍이라는 우스갯소리가 있을 정도로 네이밍은 많은 고민이 되는 부분이다. 근데 문제는 부여할 이름 후보가 너무 많아서 고민인게 아니라 도저히 쓸 이름이 없어서 고민인게 문제다. 그러다보니 요즘엔 ~ByParameter 형태의 네이밍을 메서드에 많이 이용하는 것 같다. 특히 service layer 나 repository layer 에서 많이 사용된다. @Service public class ProductService { private ProductRepository productRepo..

spring batch 를 이용해 많은 batch job 을 만들지만 배치를 테스트하기란 쉽지않다. 하지만 배치도 분명한 하나의 애플리케이션인만큼 테스트 작성에 대한 욕구가 있었는데 그것들을 정리해보고자한다. 먼저 spring batch reference 에서 테스트 코드에 대해 가이드하고있는 부분이 있는데 가이드 문서가 불친절해 제대로 테스트를 작성하기 힘들었다. 실전 엔터프라이즈 애플리케이션에서는 해당 가이드대로 했을때 도저히 테스트를 구동할 수 없었고, 많은 삽질끝에 얻은 결론을 정리하려한다. # batch job 작성 @Configuration class SampleBatch( private val jobBuilderFactory: JobBuilderFactory, private val stepB..

요즘 자바코드를 보면 클래스를 정의할때 무조건적으로 builder pattern 을 적용하는걸 심심찮게 볼 수 있다. 회사코드에서도 그렇게 작성된 코드를 쉽게 접하기도 한다. 더욱이 롬복에서 @Builder 라는, 아주 간편하게 빌더 클래스를 만들어주는 기능을 제공해주다보니 빌더 클래스를 만드는 것에 대한 부담도 없다. @Builder class Person { private String name; private int age; } 사용하는 쪽에선 이렇게 사용한다. Person p = Person.builder() .name("LichKing") .age(34) .build(); 언제부턴가 이렇게 빌더패턴이 거의 디폴트가 되다시피 한거같은데 개인적인 추측으로는 빌더패턴이 이렇게 퍼지게된건 이펙티브 자바의..

spring framework 를 이용하여 트랜잭션을 제어할 일이 생기면 대부분 @Transactional 애노테이션을 이용할 것이다. 이 방식은 가장 간단하기도하며 spring 을 공부하는 자료들에선 대부분 선언적으로 트랜잭션을 다루는 세련된 기법이라고 소개한다. spring 을 공부할때 접하게되는 대표적 키워드들중 AOP 가 있는데, AOP 를 가장 처음으로 접하게 되는 기술이기도하다. 다만 이 방식에는 몇가지 불편한점이 있는데 1. 메서드 레벨에 AOP 가 적용되기 때문에 트랜잭션 단위도 메서드 레벨로 적용(메서드 내에서 지정 불가능) 2. self invocation 에서 트랜잭션 적용 불가 가 대표적이다. 특히 2번은 spring 을 처음 접하는 주니어 개발자라면 이 문제로 인한 삽질을 한번쯤은..

spring batch 에서 JdbcPagingItemReader 를 이용해서 데이터를 조회하는 코드를 작성했다. 이후 배치 잡을 실행했는데 아래와 같은 에러 메세지와 함께 잡이 실패했다. Column 'column4' not found.; nested exception is java.sql.SQLException: Column 'column4' not found. column4 는 임의로 이름을 바꾼거고, 실제로 존재하는 컬럼명을 넣었었다. 혹시 컬럼명에 오타가 있는건가 해서 오타도 확인해보고, 실제로 쿼리를 직접 SQL 에서 실행할때는 잘 돌아가는 것까지 확인했다. JdbcPagingItemReader 를 만드는 코드도 일반적인 관례를 따랐으며, QueryProvider 를 이용했다. SqlPagin..