Struts 1.2.9 - Вопросы вокруг пользовательской интернационализации

Question

У нас есть устаревшее приложение, которое использует Struts 1.2.9. В настоящее время приложение интернационализируется стандартным способом - .properties файлов для всех ярлыков пользовательского интерфейса, ошибок, сообщений и т. Д .; <message-resouces> определение для каждого файла .properties в struts-config.xml по умолчанию Factory & MessageResources определения; <bean:message> использование во всех JSP. Это отлично поработало до сих пор, но из-за того, что приложение само по себе является основой для услуг, используемых несколькими сотнями (да 100!!) Другими приложениями внутри компании.

У нас есть требование, чтобы расширить функциональные возможности i18n следующий образом:

1. Определить пользовательский каталог для .properties файлов - так что это будет выходить за рамки классов; в основном не внутри пакета .war. Идея состоит в том, чтобы поддерживать только изменения строки сообщения, не имея необходимости передислоцировать все приложение.
2. Этот настраиваемый каталог также будет содержать сообщения о поддерживаемых приложениях - это может быть только подмножество существующих или весь набор ресурсов, специально предназначенных для этого приложения.
3. Пользовательский способ поддержки на основе запроса Locale установки - за исключением всех других соображений (стек по умолчанию, путь к классам/пакет Lookups и т.д.) это аналогично тому, как I18nInterceptor работает в Struts2 с атрибутом requestOnlyParameterName, установленными в true.

Да, я понимаю, что несколько 100 загруженных пакетов одновременно будут интенсивными в памяти, но это приемлемо в нашем случае.

Любая помощь приветствуется - будь то направление, образец кода и т.д.

Примечание: Я полностью согласен, что переход на новую платформу пользовательского интерфейса, вероятно, является лучшим решением. Но мы не можем.

TIA.

Answer 1

У меня было аналогичное требование в проект весны, а не только для i18n, а также конечных точек веб-сервисов и других свойств.

Мы выполнили это требование, добавив этот каталог, в который мы помещаем файлы свойств, в путь к классам в файле конфигурации запуска сервера.

Протестировано и работает в weblogic 11g (подготовка и производство) и на сервере tomcat (среда разработки).

Надежда помогает