우리집앞마당

이번껀 spring boot 3 로 업그레이드할때 누구나 만날만한 이슈도 아니고, 어떻게 보면 그냥 내 실수이지만 비슷한 이슈를 마주할 수 있기에 적어놓는다. 기존 spring boot 2 애플리케이션에서 circuit breaker 로 resilience4j 를 사용하고 있었다면 spring boot 3 에 맞게 resilience4j 도 버전을 올려줘야한다. 다만 resilience4j 같은 경우 spring boot 버전에 최적화된 아티팩트를 제공하고 있어서 이 부분 이름도 변경해줘야 한다. spring boot 2 spring boot 3 io.github.resilience4j:resilience4j-spring-boot2:${version} io.github.resilience4j:resili..

설정파일에 정의한 내용들을 객체에 바인딩할때 @ConfigurationProperties 애노테이션을 이용해서 주입할 수 있다. // yml file config: person: age: 33 name: LichKing // binding 할 객체의 클래스 @ConfigurationProperties("config.person") @NoArgsConstructor @Setter @ToString public class Person { private String name; private int age; } // 어디엔가 이 애노테이션을 선언해줘야 한다 @ConfigurationPropertiesScan 위처럼 정의하면 spring 컨테이너가 구동될때 Person 의 기본생성자를 이용해 인스턴스를 만들고, ..

jackson 을 이용할땐 나 같은 경우 항상 ObjectMapper 클래스를 이용했다. 그러다가 Serialization/Deserialization 에 각각 특화된 ObjectWriter/ObjectReader 클래스가 있다는걸 알게됐는데 ObjectMapper 를 사용하는 것과 어떤 차이가 있는지 알아보기로 했다. 먼저 ObjectMapper 의 가장 치명적인 문제는 스레드에 안전하지 않다는 것이다. 멀티 스레드 환경에서 공유 변수로 사용하게 될 경우 원치 않는 결과가 나올 수 있다. ObjectMapper 의 javadoc 에는 이렇게 적혀있다. Mapper instances are fully thread-safe provided that ALL configuration of the instanc..

spring security 는 확장을 위해 WebSecurityConfigurer 라는 인터페이스를 제공하고 있다. spring 은 이전부터 확장 인터페이스에 대해 좀 더 용이하게 사용하도록 기본 구현을 하는 구현체들(추상클래스 포함)을 제공하는데 WebSecurityConfigurer 는 WebSecurityConfigurerAdapter 라는 추상 클래스가 그 역할을 한다. 확장이 필요한 경우 WebSecurityConfigurer 를 직접 구현하는 경우는 거의 없다. 이는 WebSecurityConfigurer 의 javadoc 에서부터 명시하고있다. Allows customization to the WebSecurity. In most instances users will use EnableWe..

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..