Контекст приложения Spring не может загрузить файлы конфигурации

#java #spring #unit-testing #osgi #integration-testing

#java #весна #модульное тестирование #osgi #интеграция-тестирование

Вопрос:

У меня есть 2 проекта. Проект плагина, содержащий некоторые компоненты (POJO), и фрагментный проект, содержащий соответствующие модульные и интеграционные тесты. Я использую Tycho для создания этих проектов, и я хочу использовать Spring для начальной загрузки моих интеграционных тестов.

Я аннотировал свои тестовые классы с

 @ContextConfiguration(locations = { "classpath*:spring/*-config.xml" })
@RunWith(SpringJUnit4ClassRunner.class)
  

Но когда я пытаюсь создавать проекты с помощью tycho ( clean install ) или запускать тестовый класс как плагин-тест в eclipse, Spring жалуется, что в определенном контексте нет компонентов. В журнале я нашел следующие строки:

 DEBUG o.s.t.c.s.AbstractGenericContextLoader - Loading ApplicationContext for 
      locations [classpath*:spring/*-config.xml].
DEBUG o.s.b.f.xml.XmlBeanDefinitionReader - Loaded 0 bean definitions from 
      location pattern [classpath*:spring/*-config.xml]
  

Я поместил файлы конфигурации в src/main/java/spring/ и src/main/resources/spring , но spring не может их найти. Я также попытался добавить эти пути явно в bundle-classpath в манифесте.

Когда я меняю путь конфигурации на "file:spring/some-config.xml" spring, загружаются мои определения компонентов, но происходит сбой при попытке загрузить схему «context» со следующим выводом:

 Configuration problem: Unable to locate Spring NamespaceHandler for XML schema
namespace [http://www.springframework.org/schema/context]
  

Почему он не работает с префиксом classpath? И почему он работает с префиксом файла? Я думал, что префикс файла будет работать только для файловой системы, а не для файла jar… Что я делаю не так?

Заранее спасибо

Обновление: вот полное представление (фрагмент) тестового проекта:

 /
 -- src/main/java/
|    -- MyTestClass.java
|
 -- src/main/resources/
|    -- spring/
|   |    -- some-config.xml
|    -- log4j.properties
|
 -- META-INF/
|    -- MANIFEST.MF
|
 -- pom.xml
  

После того, как tycho попытался выполнить мой тестовый класс, я вижу следующие файлы в разделе target:

 /target
|
 -- classes/
     -- MyTestClass.class
     -- spring/
         -- some-config.xml
     -- log4j.properties
 -- work/   // contains the eclipse configuration (config.ini, etc.)
 -- MANIFEST.MF
 -- mybundle-xx.jar
  

Я пропустил файлы свойств и surfire. В сгенерированном файле config.ini в разделе target/work/configuration/ перечислены все пакеты, которые упоминаются в манифесте как требуемые пакеты. На них ссылаются как на файлы jar, за исключением моего пакета тестовых фрагментов. Для тестового пакета существует следующая запись:

 reference:file:C:/[...]/workspaces/workspace/my.bundle.tests
  

Правильно ли это? Это, по крайней мере, объяснило бы, почему работает префикс файла…
Но как насчет префикса classpath? Был ли скопирован манифест в нужное место в целевой папке? Я имею в виду, что он находится за пределами classes папки, на которую ссылается dev.properties .
Кроме того, log4j жалуется при запуске, что он неправильно настроен, что указывает на то, что он не может найти log4j.properties в пути к классу.

Обновление: теперь я пробую другой способ. Я прочитал эту статью, и мне показалось, что это более простой способ запустить работу. Итак, я добавил maven-surfire-plugin в свой pom и изменил тип упаковки с «eclipse-test-plugin» на «jar», чтобы tycho не запускал свой собственный плагин surefire. Но теперь я стою перед другой проблемой. Spring, похоже, предоставляет только ArtifactLocator для репозиториев maven2, а не для репозиториев p2, которые использует tycho.
Кто-нибудь знает, существует ли ArtifactLocator для репозиториев p2?

Кто-нибудь использует ту же настройку с tycho, osgi и spring для интеграционного тестирования?

Комментарии:

1. Проверьте, упакована ли ваша конфигурация контекста xml с файлом jar.

2. ДА. Файл конфигурации находится в корневой папке jar «/spring/some-config.xml «. И в манифесте добавлена запись пути к классу для «.».

Ответ №1:

Укажите spring-context-xx.jar свой путь к классу.

Пространства имен обрабатываются реализациями NamespaceHandler интерфейса. При запуске spring загружает их все и пытается проанализировать каждое пространство имен с помощью загруженных обработчиков. Если ни один из них не утверждает, что может его проанализировать, генерируется исключение. context: пространство имен анализируется с помощью ContextNamespaceHandler , которое находится в вышеупомянутом jar.

Комментарии:

1. Я добавил spring-context-xx.jar к требуемым пакетам в манифесте. Поскольку мои плагины работают в контейнере OSGi, я подумал, что этого будет достаточно. Не поддерживают ли пакеты springframework OSGi?

2. По умолчанию — я не думаю, что это так. Я думаю, что они должны быть osgi’ed

3. @coding.mof Нет, обычные пакеты не поддерживают OSGi, но пакеты OSGi существуют .

4. Я немного в замешательстве. В Spring DM doku я нашел эту ссылку . В пункте 7.4 указано, что пакеты springframework, начиная с версии 2.5, поддерживают OSGi. Я проверил это в своих версиях. Я использую Spring 3.0.6 и Spring DM 2.0.0.M1. Но ошибка с отсутствующими определениями схемы выглядит как проблема с загрузчиком классов в OSGi…

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

Ответ №2:

Используя Tycho, согласно http://blog.vogella.com/2010/07/06/reading-resources-from-plugin / Я пробовал такие места, как:

 "platform:/plugin/<host-bundle-id>/<path-to-resource>"
  

и теперь он может загружать конфигурации контекста в качестве ресурса.