[jira] [Created] (WW-5670) Dispatcher.getLocale logs "defaulting to request locale" for a locale that may not come from the request

["Lukasz Lenart (Jira)" <ji...@apache.org>]

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)