Bug 17440 - Using variant portion of Locale causes problems
Summary: Using variant portion of Locale causes problems
Alias: None
Product: Taglibs
Classification: Unclassified
Component: Standard Taglib (show other bugs)
Version: 1.0.2
Hardware: All All
: P3 major (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2003-02-26 16:45 UTC by Thomas Gideon
Modified: 2009-05-25 02:36 UTC (History)
0 users

Tarred and bzipped WAR that demonstrates problem (208 bytes, application/octet-stream)
2003-02-27 17:19 UTC, Thomas Gideon

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Gideon 2003-02-26 16:45:16 UTC
Set the preferred locale with the javax.servlet.jsp.jstl.Config class, via the
static set(HttpSession, String, Object) method.  Locale is "es_ES_foo".  When
accessing any page that uses <fmt:message/>, the default bundles are used, which
happen to be in English.  Doesn't matter if the bundles are set as the default
for the page, to a scope variable, or via Config or an init param.  However,
passing in just "es_ES" via the Config class does cause the Spanish bundles to
be properlu found and included in the LocalizationContext objects.  There are no
basename_es_ES_foo bundles, but in other, custom code, looking up
basename_es_ES_foo will successfully fall back to basename_es_ES instead of
completely failing and just returning basename.

This happens under Weblogic 6.1 sp2 and Tomcat 4.1.18.
Comment 1 Pierre Delisle 2003-02-26 23:06:43 UTC
Would love to help, but trying to parse the description of the problem
as well as to build a test case that reproduces it is asking
way too much :-(

Please provide a war file with a simple test case that reproduces the problem.
Then we'll be happy to fix any bug that may exist.

Changing state to WORKSFORME until you can provide us with that information.
Comment 2 Thomas Gideon 2003-02-27 17:19:05 UTC
Created attachment 5078 [details]
Tarred and bzipped WAR that demonstrates problem
Comment 3 Thomas Gideon 2003-02-27 17:28:25 UTC
Ignore the attachment, it is worthless.  The WAR file I created is just over 1
mb and I cannot seem to upload it directly to Nagoya.  The attachment, 5078, was
my attempt to compress the war but something went wrong and Nagoya won't let me
delete the attachment.
Comment 4 Thomas Gideon 2003-02-27 17:32:11 UTC
Get the WAR that demonstrates the problem from
http://www.gideonfamily.org/tom/bug_17440.war instead of the botched attachment.
 Sorry for the confusion.  By the way, I tried removing the JSTL jars I thought
were non-essential to reduce the size of the WAR but the JSP then failed to
compile.  I can furnish a version of the WAR without the JSTL jars if that is
Comment 5 Pierre Delisle 2003-03-03 23:47:13 UTC
Indeed there was a bug. Thanks for bringing this to our attention.
The code did not take into account the fact that an exact match could
fail because of the variant, and not necessarily because of the
Comment 6 Matt Benson 2005-12-19 16:12:29 UTC
AFAICT this was fixed on the 1.1 branch only.  When I saw pierre on infra
discussing getting back onto minotaur, I was reminded of this.  I backported
changes from the 1.1 branch to the 1.0 branch by simply overlaying
org/apache/taglibs/standard/tag/common/fmt/SetLocaleSupport.java and
org/apache/taglibs/standard/tag/common/core/Util.java.  This may bring along
some baggage but I've had no trouble as yet.

Comment 7 Henri Yandell 2009-05-25 02:36:46 UTC
Looks like this was fixed.