Hi,
I've discovered a problem which can occur in the way that we handle the
default locales. As thing are implemented currently, we populate our
supported locales based on the list provided in the
standard-faces-config.xml, plus any additional locales specified in the
application's config files. This can cause problems when doing things
like currency validation in cases where a default-locale has not been
specified in the app.
For example, suppose you are using f:convertNumber with type set to
"currency". When NumberConverter.getNumberFormat() is called, it will
attempt to get the locale from the view. The view however, in cases
where there is no default specified, follows the JSTL convention of
giving preference to the first language match instead of looking for an
exact match among the supported languages.
So, if you are expecting 'en_US' or 'en_GB', 'en' from the
standard-faces-config.xml will return a match, but the number formatter
associated with 'en' has junk for matching currency and validation will
fail. It seems to me that in cases where the application itself hasn't
specified a locale, we should fall through to calling
Locale.getDefault(). From a little experimenting, this appears to be
how the RI works as it does not exhibit the same issue, although I am
unable to look at the code to verify what its doing under the covers the
runtime works as would be expected.
Anyway, a very simple solution would be to simply remove the
<locale-config> section from standard-faces-config.xml. As far as I can
tell, it actually doesn't seem necessary in the first place and would
then leave it up to the application to specify which locales to support,
which seems to me would be the proper behavior. Does anyone with more
experience in this area have a different take on this? Is there
something I'm missing here.
Thanks,
Mike
