Major 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.
Attachments
Issue Links
- is duplicated by
-
STR-2923 PropertyMessageResources.getMessage uses loadLocale in wrong order
-
- Closed
-