Bug 7842

Summary: Formatting actions incorrectly using locale set by <fmt:locale> when 'basename' scoped attribute is present.
Product: Taglibs Reporter: Ryan Lubke <Ryan.Lubke>
Component: Standard TaglibAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED INVALID    
Severity: major    
Priority: P3    
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   

Description Ryan Lubke 2002-04-08 14:57:05 UTC
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.
Comment 1 Jan Luehe 2002-04-08 19:01:08 UTC
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.


Comment 2 Jan Luehe 2002-04-08 20:29:37 UTC
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.