프로젝트/자프링 -> 코프링 마이그레이션
-
Kotlin DSL Gradle 멀티 모듈 적용프로젝트/자프링 -> 코프링 마이그레이션 2022. 12. 27. 00:01
기존 프로젝트의 패키지 구조 기존 프로젝트는 [그림 1]처럼 하나의 단일 모듈 기반의 프로젝트로 구성되어 있습니다. build.gradle.kts에서 의존성이 관리되며 main폴더 아래에 모든 코드들이 들어가 있습니다. 이러한 구조를 멀티모듈으로 변환하고자 합니다. Why 멀티모듈? 현재는 단일 프로젝트이며 외부에 노출되는 external-api들만 존재합니다. 제공되는 기능 예시 - 사용자는 게시글을 쓸 수 있다 - 사용자는 로그인을 할 수 있다 - 사용자는 회원가입을 할 수 있다 이 상황에서 멀티 모듈을 도입하더라도 큰 의미가 없을 수 있습니다. 하지만 만약 내부에서만 사용하는 internal-api 관리자 api가 존재할 경우 이야기가 달라질 수 있습니다. 다른 프로젝트에서 internal-api를..
-
build.gradle to build.gradle.kts (Groovy를 Kotlin으로 마이그레이션)프로젝트/자프링 -> 코프링 마이그레이션 2022. 12. 11. 00:01
개요 모든 파일을 자바에서 코틀린으로 변경하였습니다. 이제 남은 것은 build.gradle의 groovy 기반의 빌드 스크립트를 kotlin으로 바꾸고자 합니다. Groovy DSL -> Kotlin DSL DSL은 특정 분야에 최적화된 프로그래밍 언어를 말합니다 예를 들면 SQL이 있습니다. Gradle공식문서에서 친절하기 Groovy를 Kotlin으로 마이그레이션 하는 문서를 제공합니다 https://docs.gradle.org/current/userguide/migrating_from_groovy_to_kotlin_dsl.html Migrating build logic from Groovy to Kotlin Declaring dependencies in existing configurations ..
-
@SpringBootApplication 자바[Java] -> 코틀린[Kotlin]으로 변경프로젝트/자프링 -> 코프링 마이그레이션 2022. 12. 6. 00:01
기존 Java의 @SpringBootApplication @SpringBootApplication public class AnthillApplication { public static void main(String[] args) { SpringApplication.run(AnthillApplication.class, args); } } Kotlin의 @SpringBootApplication @SpringBootApplication class AnthillApplication fun main(args: Array) { SpringApplication.run(AnthillApplication::class.java, *args) } https://www.baeldung.com/kotlin/spring-boot..
-
[kotlin][Mockito][Junit5] any() must not be null 에러 해결프로젝트/자프링 -> 코프링 마이그레이션 2022. 12. 5. 00:01
개요 기존의 Mockito를 활용하여 given절에 메서드의 인자로 any()를 활용했습니다. any() must not be null java.lang.NullPointerException: any() must not be null any() 함수에서 null을 리턴하므로 에러가 발생합니다. kotlin class는 final이기 때문에 mocking이 불가능하다고 합니다. 이때 any를 사용하면 발생하는 예외 -> 특정 타입으로 구체화해서 해결하였습니다. 예시) 인자가 String이기 때문에 String 특정 타입으로 구체화 ArgumentMatchers.anyString() 문제 발생 하지만 직접 만든 클래스의 경우에는 특정 타입으로 구체화하는게 불가능했습니다. 이때 별도의 라이브러리 추가없이 an..
-
Kotlin 각종 어노테이션 사용법(@Index, @Embeddable, @Size)프로젝트/자프링 -> 코프링 마이그레이션 2022. 12. 1. 00:01
@Embeddable을 data class에 붙여주자 다음과 같은 경고가 발생하였습니다. For property-based access both setter and getter should be present 이대로 실행은 되나 경고가 불편하기 때문에 해결하고자 합니다. JPA가 FIELD, 프로퍼티(getter, setter) 액세스 두 가지 방법을 사용합니다. 프로퍼티 접근은 최근에는 권장되지 않으며 getter가 존재하여 JPA가 정확히 판단하기 어려워서 나오는 경고 메시지입니다. @Column으로 필드 접근 방식을 사용하고 있다는 것을 명시하면 해결됩니다. @Embeddable data class Address( @Column val zipCode : String, val streetNameAdd..
-
Kotlin과 Lombok 컴파일 에러 해결프로젝트/자프링 -> 코프링 마이그레이션 2022. 11. 30. 00:01
Java 코드를 코틀린으로 변경하던 중 컴파일 에러가 발생했습니다. fun toBoardResponseDTO(): BoardResponseDTO { return BoardResponseDTO.builder() .id(id) .title(title) .content(content) .writer(writer) .hits(hits) .build() } 위의 코드를 호출할때 발생하였는데 에러 로그는 다음과 같습니다. Unresolved reference: builder BoardResponseDTO는 Lombok을 사용하여 @Builder를 사용합니다. 원인 문제의 원인을 이해하려면 Java 코드와 Kotlin 코드가 섞여 있는 프로젝트의 빌드 과정을 알아야 합니다. 1. Kotlin 컴파일러가 Kotlin을..
-
Kotlin + Junit 5 could not Autowire 이슈프로젝트/자프링 -> 코프링 마이그레이션 2022. 11. 28. 00:01
개요 테스트를 진행하려고 @DataJpaTest를 달아주고 @Autowired lateinit var를 수행하였으나 could not Autowire라는 메시지가 보였습니다. @Autowired constructor를 사용하여 생성자로 초기화도 수행해보지만 동일한 에러가 발생하였습니다. 해결법 해결법은 매우매우 간단했습니다. 실제 코드의 패키지구조와 테스트패키지 구조가 달랐기 때문에 컴포넌트 스캔이 제대로 일어나지 않았기 때문입니다. 패키지구조를 동일하게 맞추니 에러가 사라졌습니다.
-
게시글 프로젝트 리팩토링프로젝트/자프링 -> 코프링 마이그레이션 2022. 11. 11. 00:01
개요 약 5개월 전 Spring JPA를 처음 다루는 시점에 로그인 + 게시글을 작성할 수 있는 토이 프로젝트를 진행하였습니다. 기술을 선택하기 위한 여러 가지의 고민들을 해보고 AWS 배포까지 한 사이클을 해볼 수 있었던 좋은 기회였습니다. 하지만 시간이 지난 후 코드를 다시 되돌아보았을 때는 부족한 부분들이 많이 보였습니다. - restful 하지 않은 url - read and write를 통한 동시성, 데드락 발생 - jpa paging시 클라이언트가 필요한 값만 반환하는 것이 아니라 모두 반환 - update 하는 부분에 @Transactional(readonly =true) 걸려 있음 - 의미없는 네이밍 - 살짝 부족한 테스트 코드 - 이로 인한 게시글을 저장할 때 member를 저장하지 않음..