Я могу составить Конфигурационный файл Spring из меньших?
Я понял, что моя ошибка на самом деле вызвана тем, что файл modal.js завершился первым, прежде чем функция reportsTable закончила запуск. Мой обходной путь - удаление файла modal.js, помещение его содержимого в функцию в файле reportsTable.js и вызов этой функции каждые 1000 мс.
window.onload = reportsTable();
window.setInterval(function(){
modalSpawner();
}, 1000);
7 ответов
От Документы Spring (v 2.5.5 Разделов 3.2.2.1.) :
может часто быть полезно разделить контейнерные определения на несколько XML-файлов. Один способ затем загрузить контекст приложения, который настроен от всех этих фрагментов XML, состоит в том, чтобы использовать конструктора контекста приложения, который берет несколько местоположений Ресурса. С бобовой фабрикой бобовый читатель определения может использоваться многократно для чтения определений из каждого файла в свою очередь.
Обычно команда Spring предпочитает вышеупомянутый подход, так как это сохраняет контейнерные конфигурационные файлы, не знающие о том, что они объединяются с другими. Альтернативный подход должен использовать одни или несколько случаев элемента для загрузки бобовых определений из другого файла (или файлов). Давайте посмотрим на образец:
<import resource="services.xml"/> <import resource="resources/messageSource.xml"/> <import resource="/resources/themeSource.xml"/> <bean id="bean1" class="..."/> <bean id="bean2" class="..."/>
В этом примере, внешние бобовые определения загружаются из 3 файлов, services.xml, messageSource.xml и themeSource.xml. Все пути местоположения рассматривают относительно файла определения, делающего импорт, таким образом, services.xml в этом случае должен быть в том же каталоге или местоположении пути к классу как файл, делающий импорт, в то время как messageSource.xml и themeSource.xml должны быть в месте ресурсов ниже местоположения файла импорта. Как Вы видите, ведущая наклонная черта на самом деле проигнорирована, но, учитывая, что их считают относительными путями, это - вероятно, лучшая форма для не использования наклонной черты вообще. Содержание импортируемых файлов должно быть допустимыми бобовыми файлами определения XML согласно Схеме Spring или DTD, включая высокоуровневый элемент.
Мы делаем это в наших проектах на работе, с помощью пути к классу* загрузчик ресурса в Spring. Для определенного приложения будут загружены все appcontext файлы, содержащие идентификатор приложения:
classpath*:springconfig/spring-appname-*.xml
Учитывая то, на что Nicholas указал на меня, я нашел это в документах. Это позволяет мне выбирать во времени выполнения бобовые контексты, которыми я интересуюсь.
GenericApplicationContext ctx = new GenericApplicationContext();
XmlBeanDefinitionReader xmlReader = new XmlBeanDefinitionReader(ctx);
xmlReader.loadBeanDefinitions(new ClassPathResource("modelContext.xml"));
xmlReader.loadBeanDefinitions(new ClassPathResource("uiContext.xml"));
ctx.refresh();
Да, можно сделать это через элемент импорта.
<import resource="services.xml"/>
атрибут ресурса Каждого элемента является допустимым путем (например, classpath:foo.xml)
Да, Вы можете с помощью тега в "Основном" бобовом файле. Но что относительно, почему? Почему, не перечисляя файлы в contextConfigLocation параметрическом усилителе контекста wab.xml или массиве районов Альса бобовой фабрики?
я думаю, что несколько файлов намного легче обработать. Можно выбрать только некоторых из них для теста, просто добавить, переименовывают или удаляют часть приложения, и Вы можете boundle различные приложения с теми же файлами конфигурации (веб-приложение и версия командной строки с некоторыми перекрывающимися бобовыми определениями).
Другая вещь отметить состоит в том, что, хотя можно сделать это, если Вы не большой поклонник XML, можно сделать много материала в Spring 2.5 с аннотациями.
Вот то, что я сделал для одного из моих проектов. В Вашем web.xml файл, можно определить бобовые файлы Spring, которые Вы хотите, чтобы Ваше приложение использовало:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/applicationContext.xml
/WEB-INF/modelContext.xml
/WEB-INF/ui.xml
</param-value>
</context-param>
, Если это не определяется в Вашем web.xml, это автоматически ищет /WEB-INF/applicationContext.xml