Lukasz Lenart created WW-5670:
---------------------------------
Summary: Dispatcher.getLocale logs "defaulting to request locale"
for a locale that may not come from the request
Key: WW-5670
URL: https://issues.apache.org/jira/browse/WW-5670
Project: Struts 2
Issue Type: Bug
Reporter: Lukasz Lenart
Fix For: 7.4.0
Follow-up to WW-5668.
{{Dispatcher.getLocale(...)}} handles an unparseable {{struts.locale}} by
falling back to a locale resolved from the request, and logs a WARN saying it
is "defaulting to request locale [X]".
Since WW-5668 that fallback goes through {{resolveRequestLocale(...)}}, which
-- when {{struts.locale.validateRequestLocale}} is enabled and the
request-provided locale is not in the JVM's available-locale set -- does not
return the request locale at all. It returns the configured {{struts.locale}}
if that parses, and otherwise the JVM default. In the branch that emits this
WARN, {{struts.locale}} is by definition unparseable, so the value logged is
the JVM default.
The logged value itself is correct; the sentence describing where it came from
is not. An operator diagnosing a locale problem would read {{defaulting to
request locale [en_US]}} and conclude the client sent {{en_US}}, when in fact
the client's locale was rejected and this is the runtime default. That is the
opposite of the conclusion the log should lead to.
There is a related redundancy on the same path: the WARN branch is only reached
because {{struts.locale}} failed to parse, yet {{resolveRequestLocale(...)}}
attempts to parse it a second time before giving up.
h2. Scope / acceptance
* The message no longer asserts a source it cannot guarantee -- e.g.
"defaulting to resolved locale [X]" -- and reads correctly whether or not
{{struts.locale.validateRequestLocale}} is enabled.
* Optionally, avoid the second parse of a {{struts.locale}} value already known
to be unparseable on that path.
* No change to which locale is actually resolved; this is a diagnostics fix
only.
Only affects the 7.x line. The 6.x backport carries the same wording but will
not be changed there.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
