Можно ли разместить ресурсы Struts 1.x в другом месте, кроме каталога классов? - PullRequest
1 голос
/ 22 октября 2011

Это для Struts 1.x (я использую 1.3.10).

Я заметил, что Struts не может подобрать пакеты ресурсов в файле ApplicationResources.properties, если он не помещен где-то в стандартном пути к классам (например,com.abc.SomePackage).

Например, если я поместил файл ApplicationResources.properties в пользовательскую папку /WEB-INF/strutsResources и настроил struts-config.xml следующим образом:

<message-resources parameter="/WEB-INF/strutsResources/ApplicationResources"/>

I прочитал , что ресурсы должны находиться в пути к классам, поэтому я также попытался добавить папку /WEB-INF/strutsResources в путь к классам.Он по-прежнему не забирает ключи ресурсов.

Я дважды проверил, что папка strutsResources действительно развернута на сервере (яиспользуя Glassfish v3), так что файл там, он просто не анализируется.

PS

  1. Если вам интересно, почему я пытаюсь это сделать, я просто хотелорганизовать свой код немного лучше («лучше», IMO).Поскольку файл ApplicationResources.properties на самом деле не является классом, я хотел поместить его в папку ресурсов самостоятельно.
  2. Я проверил, что размещение файла ApplicationResources в пакете в каталоге src работает просто отлично.

Ответы [ 2 ]

0 голосов
/ 24 ноября 2011

Лучше всего оставить его на пути к классам.

Это стандартная практика - включать файлы свойств в путь к классам, особенно если вы планируете упаковать их в WAR / EAR.Вы держите его в WEB-INF, так что вы не получите никакой выгоды от его перемещения из класса, и вы просто запутаете других разработчиков, которые должны работать над проектом, и вам пришлось взломать эту работу, чтобы сделать эту работу.

Если вы хотите, чтобы ваши файлы были внешними по отношению к развертываемому WAR / EAR, то это веская причина не использовать classpath.Обычно для этого требуется определенная конфигурация в рамках развертывания, чтобы указать, где должен находиться файл.

Например, укажите местоположение с помощью

  1. аргумента JVM (например, -Dprops.file).= / config / myapp.properites)
  2. поиск из ресурса JNDI
  3. использовать PropertiesFactoryBean, если вы используете среду Spring (я использую ApplicationContext Spring со Struts 1 MVC)
  4. читать свойства из базы данных, записывая собственный класс ApplicationPropertiesDAO, который инициализирует себя при загрузке приложений (например, контакт приложения Spring, сервлет в web.xml, прослушиватель в web.xml и т. Д.)
0 голосов
/ 22 октября 2011

В конечном счете, ответ - да. Вы можете играть в некоторые интересные игры, настраивая пользовательские className и / или factory и получать сообщения, как вам угодно (в том числе из базы данных) и так далее. Это позволяет вам настроить все, что вы хотите .

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

* Как перевернуть весь текст; забавная шутка, чтобы поиграть с вашими коллегами и отделом контроля качества.

...