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

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

I had the same feeling but as I didn't understand the decision under the hood I 
wanted to stick to to existing approach confirmed by a unittest.

Right now I have dropped changing {{storage}} location but the case is with 
{{request_only_locale}} where I want to change locale only for that one 
request, not permanently. So the interceptor must handle such special case.

> 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
>              Labels: interceptors
>             Fix For: 2.5.next
>
>
> 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)

Reply via email to