![]()
간단한 트러블 슈팅이다. 문제 상황새 프로젝트를 만들어 항상 해왔던 것처럼 컨트롤러에 API 엔드포인트를 만들어 실행했더니 전에는 발생하지 않던 문제가 발생했다. 예외 발생java.lang.IllegalArgumentException: Name for argument of type [long] not specified, and parameter name information not available via reflection.Ensure that the compiler uses the '-parameters' flag.스택은 자주 쓰던 것과는 다른 점이 없었는데 이러한 예외가 발생했다. 원인파악된 원인을 간략하게 나타내자면, `@PathVariable`이나 `@RequestParam`등의 애너테이션을 사..
다른 글에서 소개했던 것처럼, 스프링 부트의 application.yaml을 이용해 Properties를 관리하는 방법은 다양한 애너테이션을 이용한 여러가지 방법이 있다. 그 중에서 내가 생각하기에 가장 객체지향스러운 방법을 오늘 포스트에서 다뤄보려 한다.@ConfigurationProperties의 단점@ConfigurationProperties는 YAML의 계층형을 따라서 자동으로 카멜 케이스의 필드와 매칭되는 설정 값을 찾아 매핑을 진행한다. 스프링 프레임워크가 아닌 스프링 부트에서 지원을 하는 애너테이션이니 주의가 필요하다. 문자열을 이용한 하드코딩이 아니기 때문에 @Value보단 더 선호되는 애너테이션이라고 생각이 드는데, setter 메서드가 반드시 필요하다는 것이 아쉽다. 불변으로 생성할 수..
![]()
DB의 정보라던지 JWT의 내용이라던지 소스코드 외부적으로 값을 세팅해 줄 필요가 있을 경우 /resources 디렉토리 아래 .properties 혹은 .yaml에서 값을 읽어올 수 있다. 스프링 부트는 기본적으로 DB를 사용할 일이 있으면 application.yaml에서 DB 연결을 위한 값을 자동으로 설정한다. 이처럼 프레임워크의 흐름에 필요한 값을 넣기 위해 사용하는 경우도 있고, 개발자가 자체적으로 값을 소스코드 외부적으로 받아오도록 할 때 이러한 Properties들을 설정할 수 있는 방법은 여러가지가 있다.왜 Properties가 필요한가?우선 소스코드 외부적으로 왜 값을 넣어줄 필요가 있을지 생각을 해보자. 웹 서비스를 만들 땐 DB의 정보가 필요하다. 만약 팀원이 여러명 있다면, 각자의..
