외부설정과 프로필1

• 프로퍼티에서 주로 변경했었는데 환경별로 흐음

• 이렇게만들면..? 번거롭지

• 이런식으로... 옛날에는 이런 번거로운 방식을 사용함.

• 이제 실행시점에서 외부주입방식 더유연하고 간편하다 !

• 중요한 원칙! 변하는것과 변하지 않는것을 분리!
• 그럼 외부설정을 어떻게 할까?

• 밑에 부분은 이런게 있다하고 편하게 듣자

외부 설정 - OS 환경 변수

• 키벨류 형식으로 잡혀있다.

• 이런 형식으로 설정

외부 설정 - 자바 시스템 속성

• 이 부분은 기계처럼 써왔던 부분인대 기억해두면 좋을거 같다.

• 이런식으로 변경하고 -D 옵션을 줘서 실행해보자

• 확인 됨.

• 커맨드 라인은 이렇게

• 허나 ? 외부설정 분리 효과는 없음 .

외부 설정 - 커맨드 라인 인수

• 이건 아무것도 안나옴!
• ide에서 추가를 해야된다.

• 여기서 추가를 해야됨

• 공백이 중요

• 배열안에 스페이스 기준으로 들어가게 됨.

• 자바 처음배울때 다 해본거 같은데.. 기억이 없다!

• 키벨류 형식이 아니라, 공백으로 구분되서 문제점이 있다 대부분이 키벨류라.

• 문제점 통 문자

• 그냥 이파트는 패스.. 뭐야 이게

외부 설정 - 커맨드 라인 옵션 인수

• 아 이거 어디서 본거같은데 이런식으로 -- 대쉬를 두개 써서했구나

• 통문자로 인식..
• 이제 스프링이 파싱할수 있도록 객체를 만들어야됨.

• 파싱이 아직안됏다.

• 대쉬가 안들어간 것이 notOptionArg

• 옵션 들어가면 키값이 나옴

• 이렇게 까지해야되나 엄청 복잡하다.
• 기존에 프로퍼티에서 넣어서 사용한게 이런 과정 까지 있었다니 신기하다
• 통문자 형식은 null이 된다 . 옵션이 아닌거다.

외부 설정 - 커맨드 라인 옵션 인수와 스프링 부트

• 빈 주입해서 만들고 명령어는 위에 옵션 명령어 쓰면

• 이런식으로 된다. 자바안에서 설정을 작성해야되다니..

• 디버그 디폴트어플리케이션 아규먼트..

• 어떤 빈을 주입받든지 ApplicationArgument 값을 주입 받으면 어디서 든지 쓸수 잇음

• 여기 까지하면 외부환경에따라 읽은 방식이 너무 다르다

• 이럴 때 스프링부트가 어떻게 한방에 추상화해서 알려주는지 알아보자

외부 설정 - 스프링 통합

• 앞서 배운 각각 방식에 따라서 변경이 일어날대? 코드를 다 수정해야 된다.
• 각 환경변수를 읽어오는 방식이 다다르기 때문에..!

• PropertySource 추상 클래스 와 구현체들을 통해 뭔가를 할수 있을듯?

• 대표적인 예시
• 읽을때도 편하게? eviroment 사용할수 있게 연결해둠

• 현재 프로젝트에 한번 활용할일 이 있으면 적용하면좋을거같다

• 이런식으로 테스트 하면면 ?

• vm 옵션에도 똑같이 나온다.

• 두개 다 이런식으로 같은 값이 나온다.

• Environmnet를 통해
• 변경되어야 될곳과 변경하지말아야될 곳을 구분해져서 편리해 졌다.

• 두개 중 우선순위는 뭐가 더 1순위 일까?

• 커맨드라인 옵션 순위가 더 우선순위를 가진다.
• 왜? 더 유연한 것이 우선권 가짐. ( 변경하기 어려운 것보다 실행시 원하는 값을줄수 있는 자바시스템 속성이 더 우선권을 가짐)
• 범위가 넓은 것보다 좁은것이 우선권 가짐. ( 자바시스템속성은 JVM 안에 모두 접근가능
  허나 커맨드 라인 옵션인수는 Main arg를 통해서 들어오기때문에 범위가 더 좁다)
• 여기서는 인수범위가 더좁기 때문에 커맨드라인 옵션인수가 우선권을 가짐.

설정 데이터1 - 외부 파일

• 기존에 프로젝트에서 사용하하는방식

• 자바를 실행하는 위치에다 같이 둔다.

• 위에 그림에서 마지막 퍼즐이 맞춰짐 PropertySource

• yml 에도 동일하게 적용 됨

• jar 실행시 설정정보를 쓸수 있음

• 전에 작성했떤 Eviroment로 다 가져 올 수 있따

• 이런 문제점이 있는지 생각도 못해봤따.

• 예를 들어 새로운값추가?

• new 2 추가 -> 소스코드추가하면 프로퍼티도 추가

• 따로 관리하면? 왜 프로퍼티도 추가했지 흐음 이어지지가 않는다..

• 필요하면 외부에두고 쓰면 유연하긴하지만 불편함이 있는데 ?

설정 데이터2 - 내부 파일 분리

• 프로젝트 내부에서 포함해서 관리 -> 빌드시점에서 함께 빌드
• Jar 하나로 설정 데이터까지 포함 관리

• 이것도 기존 프로젝트에 사용했던 방법 위에 방법은 아니었구나 착각함.

요런 식으로

• 기존에 하던 방식

• 이런식으로 환경에 따라 따로 읽힘

• vm 옵션으로 가능함

• 요런식으로 ..

• 그러나 이런식으로 보면 한눈에 전체가 들어오지 않는 단점이 있다.

설정 데이터3 - 내부 파일 합체

• 보통 프로젝트 마다 다른대 환경별로 구분했던거 같다.

• 이런식으로

• 똑같이 적용된다

우선순위 - 설정 데이터

• 로컬이 없어서 null이 나오는걸까?
• 디폴트 값이 있는걸로 알고있는데 여기는 환경을 구분해놔 디폴트 값이없는거같아서 null 같다

• 굳이 local 지정하지않아도 된다.

• properties를 무조건 위에서 아래로 설정 ?

• 프로필을 주면 우선값을 가지지만 주지않으면 기본값을

• 단순하게 문서를 위에서 아래로 순서대로 읽으면서 사용할 값 설정

• 멈추는건 dev / prod 이런 경계값전까지

• 그림처럼 이렇게
• 또 하나의 새로운 사실 2개환경 동시 가능

• 맨 아래 값이 덮어 씌어 버린다

• 아 . 디폴트로 지정되어있어도 어짜피 환경 dev 하면 dev쪽으로 다 덮어 씌워지는구나

• 이런 극단적인 예시

우선순위 - 전체

• 우선순위로 동작을 하게된다.
• 밑에 갈수록 높은 순위로 적용이 됨

• 유연하고 범위가 더좁은게 우선순위가 높다.

• 환경을 통해서 조회하는 관점에서 보면? 설정값이 추가되거나 기존값 덮어서 변경처럼 보임?
• 우선순위가 높은값 조회