В Resin3x не работает резервное разрешение ResourceBundle? - PullRequest
Новая
       13

В Resin3x не работает резервное разрешение ResourceBundle?

0 голосов
/ 03 марта 2010

Имеются следующие файлы свойств ResourceBundle:

  1. messages.properties
  2. messages_en.properties
  3. messages_es.properties
  4. messages_ {некоторая локаль} .properties

Примечание: messages.properties содержит все сообщения для локали по умолчанию. messages_en.properties действительно пуст - это просто для корректности. messages_en.properties будет возвращаться к messages.properties!

И учитывая следующие параметры конфигурации в web.xml: 

<context-param> 
    <param-name>javax.servlet.jsp.jstl.fmt.localizationContext</param-name>
    <param-value>messages</param-value>
</context-param>

<context-param>
    <param-name>javax.servlet.jsp.jstl.fmt.fallbackLocale</param-name>
    <param-value>en</param-value>
</context-param>

Я ожидаю, что если выбранный языковой стандарт - «es», а ресурс не переведен в «es», то он вернется к «en» и, наконец, к «messages.properties» (так как messages_en.properties пусто).

Вот как все работает в Причал. Я также проверил это в WebSphere.

Смола является проблемой

Проблема в том, когда я добираюсь до смолы (3.0.23). Резервное разрешение не работает вообще! Чтобы получить сообщения для отображения, я должен сделать следующее:

  1. Переименовать messages.properties в messages_en.properties (по сути, swap содержимое messages.properties и messages_en.properties)
  2. Убедитесь, что когда-либо вводят messages_en.properties также в messages_ {любой другой локали} .properties (даже если он точно такой же).

Если я не делаю этого, я получаю "??? some.key ???" в JSP.

Пожалуйста, помогите! Это сбивает с толку.

- LES

РЕШЕНИЕ

Добавить следующее в pom.xml (если вы используете maven) 

...
<properties>
    <taglibs.version>1.1.2</taglibs.version>
</properties>
...

    <!--
        Resin ships with a crappy JSTL implementation that doesn't work with
        fallback locales for resource bundles correctly; we therefore include
        our own JSTL implementation in the WAR, and avoid this problem. This
        can be removed if the target container is not resin.
    -->
    <dependency>
        <groupId>taglibs</groupId>
        <artifactId>standard</artifactId>
        <version>${taglibs.version}</version>
        <scope>compile</scope>
    </dependency>

Ответы [ 2 ]

1 голос
/ 19 марта 2010

Я не делаю Resin, так что не связывайтесь со мной, но симптомы заставляют его звучать так, будто он поставляется с плохо запеченной реализацией JSTL. Попробуйте, например, переопределить его более приличным в /WEB-INF/lib веб-приложения. Если Servlet 2.5, получить jstl-1.2.jar , или, если Servlet 2.4, получить jstl.jar и standard.jar .

1 голос
/ 19 марта 2010

Просто идея, но вы также можете попробовать добавить этот контекстный параметр: 

<context-param> 
    <param-name>javax.servlet.jsp.jstl.fmt.locale</param-name>
    <param-value>en</param-value>
</context-param>

Вполне возможно, что Ресин использует нечто подобное в качестве «запасного» языкового стандарта.

...