코드에 포함되어 있는 다국어를 일반 자바 리소스 번들을 통해 국제화시키는 방법을 소개한다.
지역화된 표시 문자열을 리소스 번들로부터 얻어오는 Utility 메소드를 작성하였다.

import java.text.MessageFormat;
import java.util.ResourceBundle;
import java.util.MissingResourceException;
import java.util.Locale;
 
import javax.faces.application.FacesMessage;
import javax.faces.context.FacesContext;
import javax.servlet.ServletContext;
 
protected static ClassLoader getCurrentClassLoader(Object defaultObject)
{
    ClassLoader loader =
          Thread.currentThread().getContextClassLoader();
    if (loader == null)
    {
      loader = defaultObject.getClass().getClassLoader();
    }
    return loader;
}
 
public static String getDisplayString(String bundleName, String id,
                                        Object params[],
                                        Locale locale)
{
    String text = null;
    ResourceBundle bundle =
        ResourceBundle.getBundle(bundleName, locale,
                                 getCurrentClassLoader(params));
    try
    {
      text = bundle.getString(id);
    }
    catch (MissingResourceException e)
    {
      text = "!! key " + id + " not found !!";
    }
    if (params != null)
    {
      MessageFormat mf = new MessageFormat(text, locale);
      text = mf.format(params, new StringBuffer(), null).toString();
    }
    return text;
}
...

이 코드는 getCurrentClassLoader라는 메소드로 시작하는데, 이 메소드는 현재 스레드의 클래스 로더나 또는 지정된 기본 객체의 클래스 로더를 리턴한다.
클래스 로더가 왜 필요할까? 리소스 번들을 로드할 때 ResourceBundle 클래스는 리소스 번들에 해당하는 파일을 클래스 경로에서 찾는다.
Utils와 같은 유틸리티 클래스는 대개 다른 클래스 로더에 의해 Web Application의 주된 클래스 경로로부터 로드된다.
만약 이 사실을 고려하지 않는다면 Utils 클래스가 WEB-INF 디렉토리에 존재하지 않는 한 getDisplayString이 올바르게 작동하는 것을 보장하지 못한다.

getDisplayString 메소드는 getCurrentClassLoader로부터 얻어온 ClassLoader 인스턴스를 정적 메소드인 ResourceBundle.getBundle에 전달하여 번들을 로드한다.
그 다음 ResourceBundle.getString 메소드에 식별자를 전달하여 호출함으로써 번들로부터 문자열을 얻어온다.
만약 저장된 식별자를 찾지 못한다면, 이 메소드는 MissingResourceException을 던진다. 이와 같은 경우에 에러 메세지를 리턴하기 위해서는 이 예외를 잡아야 한다.
파라미터의 배열이 들어있다면 MessageFormat 클래스를 사용하여 파라미터들을 문자열에 삽입한다.

이제 실제 코드에서 이 Utils 메소드를 사용하는 예를 보인다.

이 예제는 Custom 보안을 위한 Filter 클래스의 일부이다.

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
    throws IOException, ServletException{
...
HttpServletRequest httpRequest = (HttpServletRequest)request;
HttpServletResponse httpResponse = (HttpServletResponse)response;
HttpSession session = httpRequest.getSession();
 
String requestPath = httpRequest.getPathInfo();
...
String text = Utils.getDisplayString(Constants.BUNDLE_BASENAME,
                                             "PathNotFound",
                                             new Object[] { requestPath },
                                             request.getLocale());
        httpResponse.sendError(HttpServletResponse.SC_NOT_FOUND, text);
...

먼저 주목해야 할 것은 이름을 잘못 코딩하는 것을 막기 위해 리소스 번들의 이름을 Costants 클래스로부터 가져온다는 사실이다.
또한 현재의 Locale을 직접 HttpRequest객체로부터 가져왔는데, 왜냐하면 아직 FacesContext가 존재하지 않기 때문이다.¹⁾
번들 내의 문자열이 하나의 파라미터를 포함하고 있으므로 getDisplayString 메소드에 하나의 파라미터로서 requestPath를 전달한다.²⁾

이번에는 코드에서 Component의 text를 국제화시키는 예이다.

public HtmlSelectOneMenu getProjectSelectOne()
  {
    if (projectSelectOne == null)
    {
      ...
  //    projectSelectOne.setTitle("Select the project type");
      projectSelectOne.setTitle(
        Utils.getDisplayString(getApplication().getMessageBundle(),
                               "ProjectTypeTitle",
                               null,
                               getFacesContext().getViewRoot().getLocale()));
      ...
    return projectSelectOne;
  }

이번에는 JSF API를 사용할 수 있으므로, Application과 ViewRoot로부터 각각 리소스번들의 이름과 Locale을 얻어왔다.
Application.messageBundle 특성은 faces-config.xml에 설정돼 있는 번들을 리턴한다.
faces-config.xml은 커스터마이징된 메세지를 위한 용도도 있지만 표시 문자열을 지역화 하기 위해 사용될 수도 있다.
faces-config.xml에는 오직 하나의 번들만을 지정할 수 있다. 따라서 Application이 다수의 번들을 가지고 있다면, 앞의 예제와 같이 문자열 상수를 사용하여 번들을 로드해야 한다.
이 문자열은 파라미터를 갖지 않으므로 getDisplayString 메소드의 파라미터 배열에 null을 전달했다.

이번에는 코드내에서 정보를 알리기 위한 목적과 에러를 보고하기 위한 목적등으로 쓰이는 메세지를 생성하는 Utils 메소드를 소개한다.
이 메소드는 ResourceBundle로부터 새로운 FacesMessage 인스턴스를 생성시키는 Factory method이다. ³⁾

...
public static FacesMessage getMessage(String messageId, Object params[],
                                        FacesMessage.Severity severity)
  {
    FacesContext facesContext = FacesContext.getCurrentInstance();
    String bundleName = facesContext.getApplication().getMessageBundle();
    if (bundleName != null)
    {
      String summary = null;
      String detail = null;
      Locale locale = facesContext.getViewRoot().getLocale();
      ResourceBundle bundle =
          ResourceBundle.getBundle(bundleName, locale,
                                   getCurrentClassLoader(params));
      try
      {
        summary = bundle.getString(messageId);
        detail = bundle.getString(messageId + ".detail");
      }
      catch (MissingResourceException e)
      {}
      if (summary != null)
      {
        MessageFormat mf = null;
        if (params != null)
        {
          mf = new MessageFormat(summary, locale);
          summary = mf.format(params, new StringBuffer(), null).toString();
        }
        if (detail != null && params != null)
        {
          mf.applyPattern(detail);
          detail = mf.format(params, new StringBuffer(), null).toString();
        }
        return (new FacesMessage(severity, summary, detail));
      }
    }
    return new FacesMessage(severity, "!! key " + messageId + " not found !!",
                            null);
  }
}
...
public static void reportError(FacesContext facesContext, String messageId,
                                   Exception exception)
  {
    FacesMessage message = getMessage(messageId, null,
                             FacesMessage.SEVERITY_ERROR);
    facesContext.addMessage(null, message);
    if (exception != null)
    {
      facesContext.getExternalContext().log(message.getSummary(), exception);
    }
  }
...

새로운 getMessage 메소드는 getDisplayString과 비슷하다. 다만 요약문과 상세문에 따른 새로운 FaceMessage 인스턴스를 생성시킨다는 점이 다르다.
두 식별자의 유일한 차이는 상세문의 경우 “_detail”로 끝난다는 점이다. 이는 JSF가 내부적으로 표준 메세지와 커스텀 메세지를 다루는 방식이다.
reportError는 식별자에 근거하여 메세지를 로드하는 getMessage를 사용한다.

새로운 팩토리 메소드를 정의했으므로, 코드에서 하드코딩된 메세지를 이 메소드를 이용하여 변경하는 방법을 예를 들어 알아보자.

public String login()
  {
    FacesContext facesContext = getFacesContext();
    Utils.log(facesContext, "Executing AuthenticationBean.getUser()");
 
    User newUser = null;
    try
    {
      newUser = getUserCoordinator().getUser(loginName, password);
    }
    catch (ObjectNotFoundException e)
    {
      facesContext.addMessage(null,
                              Utils.getMessage("BadLogin", null,
                                               FacesMessage.SEVERITY_INFO));
 
  /*      facesContext.addMessage(null,
                              new FacesMessage(FacesMessage.SEVERITY_WARN,
                              "Incorrect name or password.", "")); */
      return Constants.FAILURE_OUTCOME;
    }
    catch (DataStoreException d)
    {
       Utils.reportError(facesContext, "ErrorLoadingUser", d);
 
  /*      Utils.reportError(facesContext, "A database error has occurred.",
                                       "Error loading User object", d);*/
      return Constants.ERROR_OUTCOME;
    }
...

변경된 부분의 getUser를 호출한 뒤 예외를 처리하는 곳이다. ObjectNotFoundException은 중요한 에러가 아니므로, 이 경우 BadLogin이라는 식별자와 함께 getMessage 메소드를 사용하여 INFO 수준의 심각도를 갖는 메세지를 추가했다.
DataStoreException은 심각한 에러이기 때문에, ErrorLoginUser 식별자와 함께 reportError를 호출했다. ⁴⁾