Yes I remember I had same dilemma. Finally I concluded with this assumption: Users themselves should use "Create Session Interceptor" [1] when needed. I'm not sure if it was a good assumption, let's wait for WW-4741's reporter answer on Aleksandr's comment.
By the way, Aleksandr, did you mean that session creation by default fixes "WW-4943 opensymphony.xwork2.util.LocalizedTextUtil can't get i18n resources" [2]? Regards. [1] https://struts.apache.org/core-developers/create-session-interceptor.html [2] https://issues.apache.org/jira/browse/WW-4943 >-----Original Message----- >From: Lukasz Lenart <lukaszlen...@apache.org> >Sent: Friday, January 4, 2019 9:55 AM >To: Struts Developers List <dev@struts.apache.org> >Subject: Re: I18nInterceptor session creation > >czw., 3 sty 2019 o 21:33 Aleksandr Mashchenko <amashche...@apache.org> >napisał(a): >> >> Hello. >> >> Can someone shed some light on why I18nInterceptor no longer creates >> session in SessionLocaleHandler#store method? [1] [2] >> >> What was wrong with previous behavior? >> >> After all, it is `Storage.SESSION` storage which should operate on >> session. If someone doesn't want to use session then `Storage.NONE` >> can be used. >> >> Currently we are facing issue when first request comes with >> `request_locale` parameter, it changes locale but doesn't store it to >> session because session is not yet created, hence second request w/o >> `request_locale` will use default locale. >> >> [1] https://issues.apache.org/jira/browse/WW-4741 >> >> [2] https://github.com/apache/struts/pull/207 > >I think the basic idea was that, it's not I18Interceptor responsibility to >create a >session. If you want to manage session on your own, the old behaviour of >I18Interceptor wouldn't allow you to do so. Maybe we should add a flag - >"forceCreateSession" or something to keep the old behaviour and allow to >disable session creation when needed. > > >Regards >-- >Łukasz >+ 48 606 323 122 http://www.lenart.org.pl/ > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >For additional commands, e-mail: dev-h...@struts.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
