[Spring Framework] ReloadedResourceBundleMessageSource의 활용

현재 진행 중인 프로젝트에 로컬라이징을 적용하다가

스프링의 강력한 기능 중 하나인 ReloadedResourceBundleMessageSource에 대하여 정리가 되어, 포스트를 작성합니다.

 

[요구사항 및 해결]

1. 다국어 지원  

  - 서버가 한국에 있다고 무조건 korean으로 나와서는 안되며, 클라이언트에서 컨트롤이 가능하도록 해야 함.

 

  > 해결 : LocaleChangeInterceptor를 등록하고, 옵션 값인 ParamName을 이용하여,  

     해당 파라미터가 클라이언트로부터 도착하면 Locale을 변경하도록 설정.  

     추가로 SessionLocaleResolver라는 것을 localeResolver라는 Bean이름으로 등록해 주어야함. 

     그 뒤에 messageSource.getMessage()를 이용하면, 파라미터로 Locale을 지정해주지 않아도,  

     서버의 Locale을 참조하여, 원하는 메시지를 찾음!!

 

  * 결론 : 기본적으로 LocaleChangeInterceptor를 등록하면, localeResolver라는 이름을 가진 Bean을 찾아서 처리를 하게 되는데,

              SessionLocaleResolver를 localResolver라는 이름으로 등록하지 않으면,  

              기존에 이미 존재하던 default Resolver(AcceptHeaderLocaleResolver)에 대하여 처리가 되버림.

              AcceptHeaderLocaleResolver는 구현부를 보면 알겠지만, 특정 파라미터에 의해서 Locale을 바꾸는 것을 지원하지 않음.

              따라서, SessionLocaleResolver로 교체를 해주면, 위에 Interceptor에서 지정한 ParamName으로 Locale을 바꾸는 기능을  

              사용할 수 있게 됨.

 

2. 서버 재시작 없이 메시지 내용 변경

   - 텍스트를 하나 바꾸었다고 재시작을 한다는 것이 말이 안된다고 느끼는 분들이 좀 많음.  

     (php만 했던 사람들은 당연히 그렇게 느끼던..) 

 

   > 해결 : ReloadedResourceBundleMessageSource에 옵션으로 CacheSeconds라는게 있음.

               이게 기본으로는 -1 (영원히 캐싱, 따라서 리로드도 하지 않음)으로 되어 있기 때문에,

               1초라도 넣어주어야 해당 주기만큼 캐싱을 하고, 캐싱된 게 없으면 변경내역을 바로 불러와서 적용을 해준다.

               Tomcat을 사용하는 경우 reloadable옵션을 false로 해줘야 사용이 가능함. (true로 쓰는 경우는 거의 없지만...)

 

  ※ .properties은 모든 부분에서 사용이 가능함. 

 

 

해결은 했는데, getMessage 자체의 defaultMessage 기능이 좀 이상하게 동작하더군요.

파라미터로 온 값에 해당하는 Locale을 못찾았으면 localeResolver에 defaultLocale로 지정한 Locale에 해당하는 메시지를 찾을 줄 알았는데, 무작정 defaultMessage에 써놓은걸 뿌려버리던.... 그래서 전 try catch를 이용해서 구현을 했답니다.ㅠㅠ

이거 말고는 특별히 문제는 없는듯...