Given: <fmt:bundle basename="some.package.Resources1"/> <c:out value="${page['javax.servlet.jsp.jstl.fmt.basename.page']}" default="Attribute not set"/> <fmt:locale value="de_DE"/> <fmt:parseDate value="Nov 21, 2000 3:45:02 AM" type="both"/> ************************************************************ The resource bundle referred to by <fmt:bundle> resolves to "some.package.Resources1_en_US". Client is sending Accept-Language request header with a value of en-US. Result: Date is unparsable by the action as it's formatted using the en_US locale, not de_DE. Section 9.2 page 9-94 of public draft spec, second bullet: "I18N default localization context If a default localation context for I18N actions is specified (via the javax.servlet.jsp.jstl.fmt.basename scoped attribute or context configuration parameter), the the locale of this default localization context for I18N actions is used as the formatting locale Formatting default localization context The formatting action itself establishes a localization context according to the algorithm described in section 9.3. This algorithm requires one piece of information: the preferred locales. The way the preferred locales ar set is exactly the same as with the I18N actions and is described in section 8.2.2" So if I interpret this correctly, if the basename attribute is present, it should be used even if <fmt:locale> was called before attempting a formatting operation.
This is not a bug according to the current state of the spec ;-) According to the spec, <fmt:bundle basename="some.package.Resources1"/> currently stores the given base name as a scoped variable (the spec, as of 4/8/02, does not yet know about "configuration variables"). The subsequent formatting action detects this scoped variable, and attempts to load the resource bundle with that base name and the preferred locale. In this case, the preferred locale has been set to "de_DE" by the preceding <fmt:locale> action. Therefore, the formatting action attempts to load the resource bundle with basename "some.package.Resources1" for the "de_DE" locale (according to the resource bundle determination algorithm from section 8.3.2), and uses the locale of the resulting resource bundle, if one is found, or otherwise establishes its own localization context (using the "de_DE" locale from the <fmt:locale> action). Since in your example the resource bundle determination algorithm does not yield any resource bundle for the given base name and "de_DE" locale, "de_DE" is used as the formatting locale, causing the parse operation to fail. Note that the expert group has proposed to change the behaviour of <fmt:bundle basename="some.package.Resources1"/> to actually load a resource bundle and store it in the new j.s.j.j.fmt.bundle configuration variable, in which case the client's preferred locale ("en_US") will be considered for the resource bundle loading and subsequent formatting action. Your example has actually demonstrated how useful the new j.s.j.j.fmt.bundle config variable is going to be.
As discussed w/ Ryan, I am closing this as "not a bug", since this is the expected behaviour according to the current spec. This test will be run again once the j.s.j.j.fmt.bundle configuration variable has been added to the spec and implemented, in which case the parse operation should work.