tomcat处理错误页面时没有语言环境?

发布于 2025-01-04 09:34:17 字数 1264 浏览 1 评论 0 原文

我有一个奇怪的问题,本地化效果很好,除了我们的错误页面。

我使用 Stripes 框架、资源包和 JSTL 标签来本地化我的页面。区域设置由 Stripes 框架确定。根据 Stripes 文档

Stripes 使用 HttpServletRequestWrapper 来调用 request.getLocale() 和 request.getLocales() 仅返回所选区域设置。这意味着不仅 Stripes 将使用正确的区域设置而无需重新确定它,而且依赖 request.getLocales 的任何其他本地化工具也应该默认为正确的区域设置。这包括 JSTL fmt:* 标签 - 很酷吧?

这在任何地方都很有效,除了发生 404 或 500 错误时,它会定向到我们的错误页面,该页面在 web.xml 中配置如下:

<error-page>
    <error-code>404</error-code>
    <location>/error.jsp</location>
</error-page>

如果我直接浏览到错误页面,本地化工作正常。例如,如果我已将语言设置为西班牙语,然后浏览到此 url,该页面将以西班牙语显示:

http ://localhost:8080/error.jsp

但是,如果我将语言设置为西班牙语,然后浏览到:

http://localhost:8080/this-page-does-not-exist-create-a-404-error

出现相同的错误页面,但以英语呈现。

为什么会这样,我该如何解决?我到处找都没有结果!

我应该补充一点,我尝试手动检查 request.getLocale() ,并将其设置为 en_US。

在设置Locale的代码中,我们还设置了一些会话属性,“lang”和“country”。

作为解决方法,我发现我可以读取这些属性并重建区域设置,但我想知道为什么会发生这种情况。

I have a strange problem, where localization is working great, except on our error pages.

I am using the Stripes framework, resource bundles and the JSTL tag to localize my pages. The locale is determined by the Stripes framework. According to the Stripes documentation:

Stripes uses a HttpServletRequestWrapper to makes calls to request.getLocale() and request.getLocales() return only the chosen locale. This means that not only Stripes will use the correct locale without having to re-determine it, but that any other localization tool that relies on request.getLocales should also default to the correct locale. This includes the JSTL fmt:* tags - cool huh?

This works great everywhere except when a 404 or 500 error happens, which directs to our error page, which is configured like this in web.xml:

<error-page>
    <error-code>404</error-code>
    <location>/error.jsp</location>
</error-page>

If I browse directly to the error page, localization works fine. For example, if I've already set the language to Spanish, then browse to this url, the page appears in Spanish:

http://localhost:8080/error.jsp

But if I set the language to Spanish and then browse to:

http://localhost:8080/this-page-does-not-exist-create-a-404-error

The same error page appears, but rendered in English.

Why is that, and how do I fix it? I've searched all over with no results!

I should add, I have tried checking request.getLocale() manually, and it is set to en_US.

In the code that sets the Locale, we also set some session attributes, "lang" and "country".

As a work around, I've found I can read these attributes and reconstruct the locale, but I would like to know why this is happening in the first place.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

何其悲哀 2025-01-11 09:34:17

您的错误页面可能不会通过 Stripes Filter。
尝试从 404 页面重定向 Stripes 页面。这可能会解决问题。

Your error page might not be going through Stripes Filter.
Try to redirect a Stripes page from your 404 page. That may fix the issue.

樱花落人离去 2025-01-11 09:34:17

事实证明,问题在于 Stripes 正在处理设置区域设置,但错误页面并未通过 Stripes 调度程序传递。解决方案是添加下面的 ERROR 行:

<filter-mapping>
    <filter-name>StripesFilter</filter-name>
    <url-pattern>/*</url-pattern>
    <servlet-name>StripesDispatcher</servlet-name>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>INCLUDE</dispatcher>
    <dispatcher>FORWARD</dispatcher>
    <dispatcher>ERROR</dispatcher>
</filter-mapping>

It turns out the problem was that Stripes was handling setting the locale, but the error pages were not being passed through the Stripes Dispatcher. The solution was to add the ERROR line below:

<filter-mapping>
    <filter-name>StripesFilter</filter-name>
    <url-pattern>/*</url-pattern>
    <servlet-name>StripesDispatcher</servlet-name>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>INCLUDE</dispatcher>
    <dispatcher>FORWARD</dispatcher>
    <dispatcher>ERROR</dispatcher>
</filter-mapping>
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文