Mailing-List: contact issues-help@shale.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shale.apache.org
Message-ID: <1677321716.1207329478748.JavaMail.jira@brutus>
Date: Fri, 4 Apr 2008 10:17:58 -0700 (PDT)
From: "Gary VanMatre (JIRA)" <jira@apache.org>
To: issues@shale.apache.org
Subject: [jira] Commented: (SHALE-485) ResourceBundle lookup failure in
 MockApplication12
In-Reply-To: <628304320.1205317569294.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/struts/browse/SHALE-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43583#action_43583 ] 

Gary VanMatre commented on SHALE-485:
-------------------------------------

What effect does explicitly setting the locale of the view root in the setUp have on this problem?

protected void setUp() throws Exception {
  super.setUp();
  facesContext.getViewRoot().setLocale(new Locale("de", "DE"));

} 

> ResourceBundle lookup failure in MockApplication12
> --------------------------------------------------
>
>                 Key: SHALE-485
>                 URL: https://issues.apache.org/struts/browse/SHALE-485
>             Project: Shale
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 1.0.4, 1.0.5-SNAPSHOT, 1.0.6-SNAPSHOT, 1.1.0-SNAPSHOT
>         Environment: Java 5, JSF 1.2, i686 GNU/Linux
>            Reporter: Tim Kroeger
>
> MockApplication12.getResourceBundle(FacesContext context, String name) is intended to lookup the resource bundle's base name prior to requesting the resource via ResourceBundle.getBundle(name, locale). In the current implementation it tries to lookup the name of the resource registered with the application, which is wrong. Consider a resource bundle added via
> 	ResourceBundle bundle = ResourceBundle.getBundle("foo.bar.resource", new Locale("de", "DE"));
> 	((MockApplication12) application).addResourceBundle("fooBarResource", bundle);
> and e.g. a validator you want to test which composes a new localized FacesMessage by doing
> 	context.getApplication().getResourceBundle(context, "fooBarResource").getString("message");
> which simulates what would happen in an application where you configured your resource bundles via faces-config.xml.
> This will throw a MissingResourceException since
>     public ResourceBundle getResourceBundle(FacesContext context, String name) {
>         if ((context == null) || (name == null)) {
>             throw new NullPointerException();
>         }
>         Locale locale = null;
>         UIViewRoot viewRoot = context.getViewRoot();
>         if (viewRoot != null) {
>             locale = viewRoot.getLocale();
>         }
>         if (locale == null) {
>             locale = Locale.getDefault();
>         }
>         return ResourceBundle.getBundle(name, locale);
>     }
> tries to lookup "fooBarResource" with it's classLoader. Instead of that, one should either do something like:
>     public ResourceBundle getResourceBundle(FacesContext context, String name) {
>         if ((context == null) || (name == null)) {
>             throw new NullPointerException();
>         }
>         if (!bundles.containsKey(name)) {
>             return null;
>         }
>         Locale locale = null;
>         UIViewRoot viewRoot = context.getViewRoot();
>         if (viewRoot != null) {
>             locale = viewRoot.getLocale();
>         }
>         if (locale == null) {
>             locale = Locale.getDefault();
>         }
>         return bundles.get(name);
>     }
> which completely drops any locale context but at least returns a resource bundle, that was added with the corresponding key
> OR
> one could go ahead and implement a solution, where only the mapping 'name -> baseName' is stored in a map instead of mappings to ResourceBundles, so MockApplication12.getResourceBundle can lookup the baseName via the provided name parameter as key to the bundles Map property and then utilize ResourceBundle.getBundle() to lookup the bundle with the desired locale. That at least is, what Sun does in it's com.sun.faces.application.ApplicationAssociate which is used by com.sun.faces.application.ApplicationImpl.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.