#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>"
и теперь он может загружать конфигурации контекста в качестве ресурса.