저번 시간에 설정 파일을 분리하는 것을 했었습니다. 이번에는 properties 파일의 설정값을 불러와 보겠습니다.
프로젝트 구조는 위와 같습니다. 다른 건 없습니다만, com.example.demo.init에 ConfigureSource 클래스가 추가되었습니다.
application.properties에는 spring.profiles.active가 있습니다. 이것의 설정값은 B입니다. 이 값을 참조해서, 설정값을 불러온다고, 이 글에서 이야기를 했던 기억이 납니다. 만약에, 이 값이 B라면 application-B.properties를 참조하게 될 건데요. 이 안에 있는 셋팅 값을 보겠습니다.
spring.server.port가 7776입니다. A의 셋팅값은 spring.server.port 값이 7773입니다.
Main 함수는 변한 게 없습니다. ConfigureSource를 보겠습니다.
먼저, Component 어노테이션이 있습니다. 이것은, @SpringBootAplication과 관련이 있습니다. 레퍼런스에 설명이 잘 나와 있습니다.
여기 안에는 ComponentScan이 있습니다. 그리고 이 문서를 보면, application이 위치한 패키지들을 scan 한다고 되어 있습니다.
com.example.other 패키지 안에 있는 test를 생각해 봅시다. 분명 이 클래스 내에도 Component 어노테이션이 있습니다.
그런데, 문제는 SpringEx1Application이 속한 패키지와는 다릅니다. 그렇기 때문에, ComponentScan을 시켰을 때 걸려들지 않습니다. 프로젝트 구조를 보면, com.example.demo 안에, com.example.demo.init이 있고, 이 안에 ConfigureSource가 있기 때문에, 해당 클래스는 Scan 범위에 들어갑니다. Test는 아니고요. 그러니, Test가 출력이 안 되는 게 맞습니다. 밑에서 실행 결과를 보여드리겠습니다.
다시 Configure 클래스로 돌아오겠습니다.
이제, ConfigurationProperties 어노테이션을 봐야 하는데요. prefix가 spring.server라고 적었습니다. 이는 초기 값 특성 중에서, 이 문구로 시작하는 것을 찾으라는 의미입니다. 그리고 8번째 줄에 port가 있었는데요. 이는, spring.server.port 셋팅 값을 불러오기 위함입니다.
7776만 출력되고, test는 안 보입니다. 이는 ComponentScan이 test 클래스를 스캔하지 않기 때문입니다. 여기서, 이런 의문이 들 수 있습니다. 어떻게 test까지 스캔하게 할 지는 추후에 더 보도록 합시다.
디자인 패턴 카데고리에 언급한 이 글에서, 객체의 완전한 상태에 대해서 다루었습니다. 그 글에서 저는, 객체가 생성되었을 때, 반드시 설정되어야 하는 값이 setting 되지 않은 상태를 불완전한 상태로 보았습니다. 그러면서 나중에 빌더 패턴이랑 연관을 지었습니다. ConfigureSource가, port 값이 객체가 생성되었을 때 반드시 setting이 되어야 했던 값이라고 해 보겠습니다. 만약에, 생성이 되었어도, port 값이 null이였다면, 불완전한 상태입니다.
setPort 메서드를 아래와 같이 바꾸고 실행해 보았습니다.
null, 7776이 나왔습니다. 불완전한 상태에 있었다는 이야기입니다. port를 설정하는 일을 setter가 아닌, 생성자에서 할 수 없을까요? 이 부분도 조금만 더 고민해 봅시다.
'웹 > 스프링부트' 카테고리의 다른 글
spring boot 외부 jar 설정 파일을 읽어 봅시다. (2) | 2021.06.16 |
---|---|
spring boot constructorbinding : 생성자로 binding을 시킨다. (0) | 2021.02.01 |
spring boot profile 설정 파일을 분리해 봅시다. (1) | 2021.01.11 |
mybatis generictokenparser : sql문으로 만들어질때 ${}은 어떻게 대치되는지 뜯어봅시다. (0) | 2020.06.10 |
mybatis $ # 차이를 알아봅시다. (0) | 2020.06.07 |
최근댓글