Thanks for the reply, and you read it correctly, if there's a locale
parameter, use that if not check the session, otherwise go with the browser
setting.  And yes, I've confirmed that the locale is not null.  Here is the
information I'm getting in my logs from all the debugging statements:

[10:08:43.179] I18NFilter.doFilter: Processing Request for
/canada/logout.jsp
[10:08:43.179] I18NFilter.doFilter: Using Locale from Request - en_US
[10:08:43.179] I18NFilter.doFilter: Session (abcWr_wP-sVd1_Us3Md7q) is new
and is valid
[10:08:43.179] I18NFilter.doFilter: javax.servlet.jsp.jstl.fmt.locale=en_US
[10:08:43.616] ShowConfigSettingsTag.doStartTag: JSTL Configuration Settings
(abcWr_wP-sVd1_Us3Md7q)
[10:08:43.616] ShowConfigSettingsTag.doStartTag:   *
javax.servlet.jsp.jstl.fmt.locale null
[10:08:43.632] ShowConfigSettingsTag.doStartTag:   *
javax.servlet.jsp.jstl.fmt.fallbackLocale null
[10:08:43.632] ShowConfigSettingsTag.doStartTag:   *
javax.servlet.jsp.jstl.fmt.localizationContext
com.vsp.canada.resources.application
[10:08:43.632] ShowConfigSettingsTag.doStartTag:   *
javax.servlet.jsp.jstl.fmt.timeZone null
[10:08:43.632] ShowConfigSettingsTag.doStartTag:   *
javax.servlet.jsp.jstl.sql.dataSource null
[10:08:43.632] ShowConfigSettingsTag.doStartTag:   *
javax.servlet.jsp.jstl.sql.maxRows null
[10:08:43.632] ShowConfigSettingsTag.doStartTag: Struts Configuration
Settings
[10:08:43.632] ShowConfigSettingsTag.doStartTag:   *
org.apache.struts.action.LOCALE en_US

As you can see in the I18NFilter output that it has decided to use the
locale from the request (i.e. the user's browser setting) and that it has a
new valid session.  Then I added a Custom Tag that just dumps a bunch of
information to the logs (the ShowConfigSettingsTag) and all the JSTL
settings are null, but the Struts locale seems fine???  Weird.
 (*Chris*)

On 11/7/06, Christopher Schultz <[EMAIL PROTECTED]> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris,

Chris Pratt wrote:
> I am having a strange problem with JSTL locale's after
Session.invalidate.
> I am using JSTL as the main TagLib with Struts 1.2.9.  So to keep both
> systems in sync, I have a servlet filter that executes this code:

[snip]

>    if(locstr == null) {
>      if((locale = (Locale)ses.getAttribute(Globals.LOCALE_KEY)) == null)
{
>        locale = req.getLocale();
>      }
>    } else {
>      locale = new Locale(locstr);
>    }

An I reading this right? You have an optional request parameter called
"locale" that you can use to set the locale to something specific. If
that parameter is not found, then you check the session for Struts's
locale. (Note that the session has just been invalidated, so this is
likely to return null in this). If struts doesn't have one, then you use
the locale of the request (presumably from the client's provided headers).

>    if(locale != null) {
>      ses.setAttribute(Globals.LOCALE_KEY,locale);
>      Config.set(ses,Config.FMT_LOCALE,locale);
>    }
>    chain.doFilter(req,res);

It looks like that ought to do it. Are you sure you aren't ending up
with a NULL locale object in this code?

> This works great except when, after the LogoutAction calls
> Session.invalidate(), I redirect to a "Logout Success" page.  For some
> reason that page picks up the French text from the
> application_fr.properties
> resource file for the JSTL tags, but not for the Struts tags.

That suggests that Globals.LOCALE_KEY isn't set properly. Can you dump
out the contents of the session in various places? For instance, what
does the session contain both before and after this call:

chain.doFilter(req, res);

I haven't used the JSTL before... I assume Config.set(ses, foo, bar)
basically does ses.setAttribute(foo, bar), eh?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFUN129CaO5/Lv0PARAnwfAKCVnQ0fabblJ5jrSjYAeiqS9v8x5gCfd2M9
p9uCdcUZiP1W47nIhMVuvJ4=
=LPOU
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to