Bug 1257618
Summary: | "Console Client Resources" page always use the browser language | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Christophe Fergeau <cfergeau> |
Component: | rhevm-branding-rhev | Assignee: | Alexander Wels <awels> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | meital avital <mavital> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.6.0 | CC: | awels, gklein, lsurette, mavital, mgoldboi, rbalakri, Rhev-m-bugs, srevivo, ykaul |
Target Milestone: | ovirt-3.6.0-rc | ||
Target Release: | 3.6.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 3.6.0-15 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-04-20 01:31:00 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Christophe Fergeau
2015-08-27 13:10:41 UTC
@Alexander - this would require having this page go through our locale filter (or similar) that we have, I believe? is that possible? Looking at the console client resources web.xml it makes reference to the locale filter. So one of two things is happening. 1. Because the console client resources is in its own ear file it doesn't have access to the correct class and thus isn't applying the filter. At which point I guess maybe jboss is setting the global locale to the browser Accept header value. 2. It does have access to the filter, but it can't read the cookie with the locale in it. One of the fallback mechanisms in the filter is to use the locale the browser passes to it. The order goes like this: a. Use the locale parameter. b. If no parameter, use the locale cookie. c. If no cookie, use the Accept header from the browser. d. If no header, default to US English. The most likely thing we are seeing is option 2.c where the cookie cannot be read and it falls back to the browser accept header. The cause of the issue was two fold: 1. The web.xml didn't have the correct filter statements to invoke the LocaleFilter (which reads the cookie). 2. The resource page didn't have the statement to read the locale once it was available. The associated patch fixes both. Verified - Version: 3.6.0.3-0.1.el6 |