Bug 190185 - browser caching is causing issues with locale preference changes
browser caching is causing issues with locale preference changes
Product: Red Hat Satellite 5
Classification: Red Hat
Component: i18n (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kevin A. Smith
Beth Nackashi
Depends On:
Blocks: 187135
  Show dependency treegraph
Reported: 2006-04-28 11:56 EDT by Beth Nackashi
Modified: 2007-10-23 22:27 EDT (History)
1 user (show)

See Also:
Fixed In Version: rhn410
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-19 18:33:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Beth Nackashi 2006-04-28 11:56:58 EDT
Description of problem:

Here's an IRC chat I had with Kevin:

<beth-hm> ksmith: I have browser preference set to korean, and so the RHN pages
are happily displayed in korean when I'm not logged in ...
<beth-hm> ksmith: then I log in and change RHN locale to german.  But only some
of the content is displayed in german from that point forward, the rest is still
in korean.  The only way to get all german is to close/reopen the browser.  That
doesn't seem right to me.
<ksmith> beth-hm: that is browser caching in action. that'll require some
investigation to figure out the best way around that. 
<ksmith> beth-hm: open a bug and assign it to me

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  See chat session above.
Actual results:

Expected results:

Additional info:
Comment 1 Beth Nackashi 2006-04-28 11:59:04 EDT
And even closing/reopening the browser doesn't completely fix it.
Comment 2 Kevin A. Smith 2006-04-28 15:56:33 EDT
Sadly, browser caching does not completely explain the reported behavior. I
enabled Struts' no-caching support via the following XML snippet in

   nocache="true" />

And verified that the appropriate headers were being sent to the browser. This
cleared up a few minor instances of wrongly cached content. This didn't fix the
bulk of the problem.

After more digging I've unearthed a multi-layer problem which will take a bit to
fix correctly. Here are the issues I know about:

1) We are using the <%@ include %> directive to include our html fragment files. 
This directive is meant for static content and has caching and other
persistence-related problems when used with dynamic content
(http://www-128.ibm.com/developerworks/java/library/j-jsp04293.html). The
<jsp:include> tag should be used since it is more compatible with dynamic content.

2) Fragment files end in .jspf.
By default the jsp servlet is mapped to *.jsp and *.jspx. Once I addressed #1
and converted the user locale preferences page to use <jsp:include> I had
problems getting the include fragment to execute, ie I was seeing raw,
unexecuted jsp tags in the browser (<c:out>, <c:if>, etc). I was able to fix
that by adding the following servlet mappings to web.xml:



3) Fragment files do not contain necessary taglib declarations
In fixing #2 I discovered that some custom tags were not executing. Further
digging revealed that most of our jsp fragments do not include necessary taglib
declarations, instead relying on the including page to declare the necessary tags.

After addressing all the above issues for the user locale preferences page I am
still not seeing localized text change uniformly when the user's locale changes.
My current suspicion is that something in our templating mechanism is getting in
the way. My investigation continues. 
Comment 3 Kevin A. Smith 2006-05-01 10:17:26 EDT
Discovered the actual cause of the problem this morning. Struts' MessageResource
class caches, IMHO very very incorrectly, the first value resolved for a given
localized string. Subsequent calls return the cached value instead of performing
the lookup again. This ultimately has the effect of resolving only one
translation per localized string -- meaning that a string can be resolved to
only one language, period.

I was able to workaround this behavior by clearing MessageResource's cache in
each call to getMessage(). I've verified that this fix works without the fixes
noted in my previous update. I still feel that the above items are things which
should be addressed, but since they are not required to fix the actual problem
reported I will leave them out of the committed fix.
Comment 4 Kevin A. Smith 2006-05-02 16:05:51 EDT
Test Plan:

1) Login to RHN

2) Click the Locale Preferences selection

3) Select a locale and save

Expected Result: The entire locale preferences page should render in the new
Comment 6 Beth Nackashi 2006-06-05 17:27:24 EDT
Verified.  I moved locales all over the place, changed the browser locale, etc.
 Looks good.
Comment 7 Beth Nackashi 2006-07-19 18:33:15 EDT
closing -- currentrelease

Note You need to log in before you can comment on or make changes to this bug.