Bug 18525 - BundleTag keep the first Locale found for subsequent sessions
Summary: BundleTag keep the first Locale found for subsequent sessions
Status: RESOLVED FIXED
Alias: None
Product: Taglibs
Classification: Unclassified
Component: I18N Taglib (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal with 6 votes (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
: 16932 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-03-31 15:01 UTC by Patrick Samson
Modified: 2004-11-16 19:05 UTC (History)
1 user (show)



Attachments
BundleTag patch (4.23 KB, patch)
2004-06-02 15:47 UTC, Patrick Samson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Samson 2003-03-31 15:01:51 UTC
Suppose a i18n:bundle with localeRef="theRef", and
the attribute for 'theRef' is not defined. The most
appropriate Locale is determined as expected, and
memorized as an attribute in the http session.
But _locale is also set. So when this bundle will be
reused by a second http session (another workstation),
then in findBundle() _locale is not null and used.
Consequences for the second http session:
- the browser preferences are ignored,
- the session attribute is not set (which thows a null
pointer exception in my code, but it's up to me)

Workaround: add locale="<%=null%>"

I think that in findBundle(), _locale should never be
set, but a local variable used instead, as done for
_bundle in MessageTag.getBundle().

Note: this bug may be similar to #16932
(i18n:message uses wrong resource bundle).
Comment 1 Gareth Jones 2003-04-14 11:55:23 UTC
I've experienced the same problem. It's caused by tag pooling (we're using 
tomcat 4.1, it doesn't happen in tomcat 3.3), the bundle tag does not reset 
its state at the end of a request, keeping the _locale set to the value it had 
at the end of the first request. I fixed it for us by adding a call to the 
release() method at the end of the doEndTag() method. 
Comment 2 Patrick Samson 2003-06-10 11:08:49 UTC
Thanks Gareth for your comments.
Even if it works, I don't believe that a call to release() is the correct 
design. As I suggested in my report, I'm convinced that _locale should not be 
set in findBundle(). My implemented and working fix in findBundle() is :
        // Add a local variable to keep _locale unchanged.
        // Replace any further reference to _locale by this new variable
        // in this method.
        Locale locale = _locale;

Additional note:
I had to create my own version of the i18n library to fix this bug.
I don't want to blame anyone but I expected an action and there is none, more 
than 2 months after the opening. It's the same for my other bugs #18521, 18523 
and 18524.
Just wonder if anybody is taking care of this library. tdawson seems dead.
Please inform the community :)
Comment 3 Patrick Samson 2004-04-07 09:26:50 UTC
Additional fix:

Because of the reuse mecanism, any internal member variable has to be
initialized. So add this code at the very beginning of doStartTag()
in BundleTag.java

    	// initialize internal member variables
    	_bundle = null;

This will fix a MissingResourceException on a MessageTag
after a session time-out.

Note: to confirm my previous fix, member variables associated with attributes
(such as _locale) must be read-only in the tag processing. Only the JSP
container is allowed to write them through setXXX() methods.
Comment 4 Patrick Samson 2004-06-02 15:47:55 UTC
Created attachment 11730 [details]
BundleTag patch
Comment 5 Felipe Leme 2004-06-04 04:51:20 UTC
Patrick,

>I don't want to blame anyone but I expected an action and there is none, more 
>than 2 months after the opening. It's the same for my other bugs #18521, 18523 
>and 18524.
>Just wonder if anybody is taking care of this library. tdawson seems dead.

The I18N is not "dead", but most of its features were made obsolete by JSTL's
Format taglib.

>Please inform the community :)

Yes, we might be creating a new category for obsolete taglibs.



Anyway, I have applied your fixes. Thanks.
Comment 6 Felipe Leme 2004-06-15 03:16:31 UTC
*** Bug 16932 has been marked as a duplicate of this bug. ***