Seemingly random message resources in another language

• Key: STR-2925
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Niall Pemberton
• Reporter: Robert Rodewald
• Component/s: Core
• Fix Version/s: 1.3.6

Description

Suppose you have two properties files:
- ApplicationResources_de.properties (German)
- ApplicationResources.properties (English, default)

Both contain a key named "street".

The JVM's default locale is de_DE (German, Germany).

Now you access the struts application with a browser which is set to accept de_DE.

The class PropertyMessageResources is trying to get this key from a properties file with the extension "de_DE" and doesn't find one. Then it searches for a properties file with the extension "de" and finds one. In this process the key "de.street" is created internally. Additionally the value is "cached" under the key "de_DE.street" in case the user will access it again.

Now suppose that another user with a browser set to accept en_US accesses the application after this first user.

What happens is that the class PropertyMessageResources first tries "en_US" extension, then "en" extension and finds nothing. In the next step the default locale of the JVM is tried, which in this case is "de_DE". No properties file is loaded as there is none, but the "cached" key "de_DE.street" is used, which is NOT correct. This leads to seemingly random labels in another language as other keys, which haven't been accessed with the default locale earlier, may not have been "cached" in this way and are taken from the properties file without any extension (and are therefore correctly in English).

Further investigation of the matter yields the following results:
o JSTL (Apache implementation) tries all variants of the requested locale and then the one without any extensions (en_US -> en -> none)
o Java (ResourceBundle) tries all variants of the requested locale, all variants of the default locale and then the one without any extensions (en_US -> en -> de_DE -> de -> none)
o Struts tries all variants of the requested locale, the full default locale and then the one without any extension (en_US -> en -> de_DE -> none) (and "caches" the value in a way that creates the aformentioned bug)

I agree with STR-2077 that this deviation from the Java standard creates confusion and I think that the easiest way of solving the two problems would be to use the standard ResourceBundle mechanism as suggested in STR-1340. An even easier solution would be for Struts to ignore the default language of the JVM and thus make it react like JSTL (which is very desirable anyway as many of us use JSTL and Struts-EL in combination).

The problem can be avoided by setting the default locale of the JVM to the language of the default properties file.

Comments

[Niall Pemberton]

I have added a "compatibility mode" configuration option to PropertyMessageResources. It can now be configured to operate in one of three modes:

1) "Default" mode - default, backwardly compatible, Struts behaviour (i.e. the way its always worked).
2) "JSTL" mode - compatible with how JSTL finds messages (fixes STR-2925)
3) "Resource" mode - compatible with how Java's <code>PropertyResourceBundle</code> finds messages (fixes STR-2077)

To configure for "JSTL" mode:

    <message-resources parameter="mypackage.MyMessageResources">
        <set-property key="mode" value="JSTL"/>
    <message-resources>

To configure for "Resource" mode:

    <message-resources parameter="mypackage.MyMessageResources">
        <set-property key="mode" value="resource"/>
    <message-resources>

http://svn.apache.org/viewvc?view=rev&revision=480549