[prev in list] [next in list] [prev in thread] [next in thread] 

List:       struts-dev
Subject:    [jira] [Commented] (WW-4734) I18Interceptor ignores session or cookie Locale after first lookup fail
From:       "Lukasz Lenart (JIRA)" <jira () apache ! org>
Date:       2017-01-28 8:17:24
Message-ID: JIRA.13034708.1484323979000.24816.1485591444432 () Atlassian ! JIRA
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/WW-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15843979#comment-15843979 \
] 

Lukasz Lenart commented on WW-4734:
-----------------------------------

Great to hear that, thanks a lot :)

> I18Interceptor ignores session or cookie Locale after first lookup failure
> --------------------------------------------------------------------------
> 
> Key: WW-4734
> URL: https://issues.apache.org/jira/browse/WW-4734
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.5.8
> Reporter: James Chaplin
> Assignee: Lukasz Lenart
> Priority: Blocker
> Labels: interceptors
> Fix For: 2.5.10
> 
> 
> In Struts 2.5.5 and prior 2.5.x/2.3.x, the I18nInterceptor honoured the locale \
> state set programmatically via session (e.g. \
> session.put(I18nInterceptor.DEFAULT_SESSION_ATTRIBUTE, localeForUser); ). Struts \
> 2.5.8 ignores a locale state set programmatically via session (or at least it does \
>                 so after the 1st failed lookup).
> *Issue cause: Changes in 2.5.8 storeLocale()/readStoredLocale() behaviour causes \
> "storage == Storage.NONE" after 1st lookup failure, and i18nInterceptor will never \
> again check session/cookie scopes for a locale.  Appears to have been introduced \
>                 with changes for WW-4722.
> *Bug elements:
> 1) readStoredLocale() - Never checks session/cookie level for a saved locale (after \
> first lookup failure sets "storage = Storage.NONE"). 2) readStoredLocale() - The \
> "if block" checks are inverted.  When "storage == Storage.COOKIE" it checks \
> session, when "storage == Storage.SESSION" it checks cookie (appears this was \
> addressed in update to WW-4722 on 2017/01/11). 3) LocaleFinder/saveLocale() - No \
> longer provides default lookup at session level, no longer preserves the storage \
>                 level where the lookup succeded.
> *Suggested remedy:
> 1) Restore logic equivalent to 2.5.5 and earlier that will always check session and \
> cookie scopes for Locale, irrespective of what the current i18n interceptor \
> instance's storage value is set to. Change readStoredLocale() to check all scopes, \
> restore storage scope state to LocaleFinder and calls to saveLocale().  Use \
> LocaleFilender's scope state (tracking immediate request's locale storage level) \
> during request processing (and if possible, leave i18n interceptor's scope \
> fixed/unchanged). 2) Add logic to I18nInterceptor that preserves the initially \
> configured storage type/scope for the lifetime of the i18n interceptor.  This could \
> be done by adding a new protected member to I18nInterceptor (e.g. protected \
> configuredStorage), which gets initialized similarly to "storage" but only modified \
> in the initial setLocaleStorage() call (so its value stays intact until explicitly \
> changed by configuration). Either way it appears the I18nInterceptor needs a \
> mechanism to ensure that it will always look for Locale at the session/cookie level \
> (or at the very least the level that was initially configured for the interceptor), \
> irrespective of what the current storage value is set to.  Without such logic the \
> i18n interceptor stops looking for anything other than the request/invocation \
> context level (after the first lookup failure, irrespective of original storage \
> setting).  Tracking the configured storage scope (global) and the immediate \
>                 request's scope (local) separately might be appropriate.
> *Note: API documentation for I18nInterceptor "storage" parameter appears incorrect \
> as well.  The new configuration parameter in 2.5.8 should indicate "localeStorage" \
> for configuring the locale storage parameter (it indicates "storage" currently, but \
> that fails as it doesn't match the setter's name).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[prev in list] [next in list] [prev in thread] [next in thread]