Несколько источников сообщений в конфигурационных файлах Spring - PullRequest
3 голосов
/ 22 декабря 2009

наше веб-приложение использует Spring 2.5. Он состоит из нескольких модулей, каждый из которых может содержать дополнительные файлы контекста Spring, которые загружаются автоматически (в один контекст приложения). Мы хотим, чтобы каждый модуль предоставлял дополнительные пакеты ресурсов (для поддержки I18N).

Spring поддерживает интернационализацию, регистрируя bean-компонент с именем messageSource в файле конфигурации, но это предполагает, что я точно знаю, каково полное имя файла класса или свойств, который содержал строки перевода. Это проблема, потому что другие модули могут иметь свои собственные файлы свойств, помещенные в другое место. Поэтому я ищу способ позволить каждому модулю определять свой собственный источник сообщений со своими собственными пакетами ресурсов, и я не знаю, как это сделать.

Кто-нибудь знает решение этой проблемы?

Спасибо.

1 Ответ

0 голосов
/ 02 февраля 2010

Я использовал источники сообщений весной для поддержки i18n. В моем случае мне был нужен только один, поэтому было легко внедрить один источник сообщений, который мне был нужен, в создаваемый мной компонент службы.

Я надеялся увидеть что-то похожее на то, что я предложу позже, в самих источниках Spring. Но я не вижу ничего, что могло бы объединить разнородные источники сообщений. Если все они будут частью пакета ресурсов, такого как файлы свойств, я уверен, что вы могли бы написать оболочку для ResourceBundleMessageSource, которая могла бы динамически обновляться при регистрации bean-компонентов.

Однако, если вы хотите объединить разнородные источники сообщений, я бы предложил это. Создайте объединяющий компонент источника сообщений, который при загрузке запрашивает ApplicationContext для компонентов типа MessageSource.class. Этот агрегирующий компонент может затем позволить каждому источнику попытаться разрешить ключ и отформатировать сообщение. В зависимости от того, сколько у вас есть исходных классов files / msg, вы можете разрешить агрегирующей реализации определять приоритеты, какие из них она пытается использовать в первую очередь. Если производительность становится проблемой, вы также можете кэшировать, какой источник разрешил, какие ключи, чтобы агрегатору не приходилось каждый раз угадывать.

...