Return-Path: Delivered-To: apmail-struts-dev-archive@www.apache.org Received: (qmail 38647 invoked from network); 30 Jun 2006 19:32:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 30 Jun 2006 19:32:15 -0000 Received: (qmail 41470 invoked by uid 500); 30 Jun 2006 19:32:12 -0000 Delivered-To: apmail-struts-dev-archive@struts.apache.org Received: (qmail 41428 invoked by uid 500); 30 Jun 2006 19:32:12 -0000 Mailing-List: contact dev-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list dev@struts.apache.org Received: (qmail 41417 invoked by uid 99); 30 Jun 2006 19:32:12 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Jun 2006 12:32:12 -0700 X-ASF-Spam-Status: No, hits=2.1 required=10.0 tests=SPF_HELO_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [206.252.142.4] (HELO milhouse.priv.jgsullivan.com) (206.252.142.4) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Jun 2006 12:32:06 -0700 Received: from [192.168.2.110] (maximus.jgsullivan.com [68.79.151.2]) by milhouse.priv.jgsullivan.com (8.12.11.20060308/8.12.11) with ESMTP id k5UJVj0O018576; Fri, 30 Jun 2006 15:31:45 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060630183628.79529.qmail@web32609.mail.mud.yahoo.com> References: <20060630183628.79529.qmail@web32609.mail.mud.yahoo.com> Date: Fri, 30 Jun 2006 14:30:45 -0500 To: Paul Benedict , Struts Developers List From: Joe Germuska Subject: Re: Locale resolver (Re: WW/SAF2 i18n & Cintoo Messages) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N At 11:36 AM -0700 6/30/06, Paul Benedict wrote: >Some further reflections: > >WW and SPR both use ThreadLocal to store the locale of the thread's >request. However, there still needs to be a shared object that can >set/retrieve the local across web frameworks. > >So I 100% agree with the ThreadLocal use, but it is not directly >relevant to my question. That would be an implementation of the >locale resolver, in which it would expose the locale in the thread >for a particular framework. On the other hand, perhaps using a thread local is a more elegant strategy than requiring a specific mechanism which looks for a specific object in the ApplicationContext and uses a specific reflection mechanism to find a locale. At 10:53 AM -0700 6/30/06, Paul Benedict wrote: >3) Modify RequestUtils.getUserLocale to lookup the stategy first and >use it. RequestUtils will have a pre-built strategy for doing >session look-up, to implement requirement #1 (see above). That is, there are lots of ways to make sure that Globals.LOCALE_KEY points to the right locale, and you could leave the details which you specify (to do with Globals.LOCALE_RESOLVER_KEY) more up to the implementor. I might just write a ServletFilter instead of putting in a LOCALE_RESOLVER, or I might write a custom chain command. It seems to me better to leave the things which need the Locale ignorant of how to find it. In fact, you could easily replace the "SetLocale" command with another that consulted cookies or request parameters. Joe -- Joe Germuska Joe@Germuska.com * http://blog.germuska.com "You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new." -- Robert Moog --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org