미리적는 결론: java파일에서 spring.profiles.active을 설정해 주는 부분이 있나 확인해보자.
현재 회사에서 사용중인 globals.properties는 하나의 파일안에
local, dev, prod을 주석으로 관리 하고 있었다.
근데 이러다 보니 배포할때나, globals properties를 변경할 때
일일이 해당 하는 부분의 주석을 풀고 다른 부분을 주석해야하는 번거로움이 있었다.
어떻게 보면 그렇게까지 큰 번거로움은 아니지만,
휴먼 에러가 발생 할 수 있는 가능성이 존재했고
가끔 실제로 주석을 잘 못 풀거나, maven install하면서 clean을 하지 않으면
제대로 install이 되지 않아 globals.properties의 주석이 의도한대로 풀리지 않을 때도 있었다.
그래서 이번에 globals-local,dev,prod이런식으로 분리하려고 했다.
사실 시작하기 전 까지만 해도 쉬울줄 알았는데,
막상 해보니 이상한곳에서 자꾸 error가 났다.
tomcat vm_options에 spring.profiles.active=local 이런식으로 값을 설정해주었는데,
에러로그에 나오는 불러오는 globals properties이름은
globals-postgres,security.properties이런식으로 적혀있었다.
이 부분이 왜 이렇게 되는지 처음에는 감을 못잡아서
xml에서 쓰는 문법 에러인가 해서 한참을 헤매고...
(왜냐면 중간에 그냥 하드코딩으로 globals-local이런식으로 넣어도
compile오류가 나서 그랬었다. 아마 이건 일괄적으로 다 변경하지 않고, 다른 설정도
맞지 않게 고쳐서 그랬던것 같다.)
${spring.profiles.active}
-> #{systemProperties['spring.profiles.active']}
-> ...(몇가지로 더 바꿨었는데, 잘 기억이 나지 않는다...)
여러가지로 한참을 바꿔보고 있다가
spring.profiles.active로 검색을 해보니 WebServletContextListner파일에
spring.profiles.active를 설정 해주는 부분이 있었다...
이 부분에서 db, security타입을 profile로 설정하고, context xml에서
그 값들로 profiles로 구별해서 쓰고 있었다.
그래서 처음에는 이 형태를 그대로 유지해서 쓸까 하다가,
그런데 어차피 datasource.xml에서 쓰는 beans profiles는 test코드 작성을 위해 뺏어야 했고,
security level도 local, dev, prod모두 같기 때문에
spring.profiles.active set 해주는 부분을 주석 처리하고
datasource부분은 중간에 넣던 db명들을 빼도록 해서 범용성 있게 쓸 수 있도록 했다.
나머지 context xml에서도 <beans> 태그에서 profile=""부분도 제거하니 의도한대로 잘 동작했다!
생각보다 시간이 오래걸렸지만 아주 뿌듯한 하루였다.
