Да, действительно, нам пришлось обернуть генерацию пакета WireMock с помощью механизма PaxUrl Wrap в отдельный файл функций:
<features name="wiremock-${project.version}" xmlns="http://karaf.apache.org/xmlns/features/v1.4.0">
<feature name="wiremock" version="${project.version}">
<feature prerequisite="true">wrap</feature>
<bundle>
wrap:mvn:com.github.tomakehurst/wiremock-jre8-standalone/2.21.0$Bundle-ClassPath=.
</bundle>
</feature>
</features>
Здесь очень важно правильно настроить пространство имен XML, а именно, для адресной версии v1.4.0 в противном случае prerequisite
бесполезен.Еще одна ловушка, в которую я вступил раньше, это не принятие автономной версии WireMock.
Затем в конфигурации PaxExam я только что установил функцию:
features(maven().groupId("com.company.wiremock").artifactId("wiremock-feature").type("xml").classifier("features").version("1.0.0-SNAPSHOT"), "wiremock"),
Когда дело доходит до инициализации WireMockServer в ваших тестах, чтобы ресурсы в новом сгенерированном WireMock-Bundle моглибыть загруженным через ClassLoader.getResource()
(внутреннее содержимое этой библиотеки), вы должны сделать это здесь в своем тесте, в противном случае Bundle-Classloader этого WireMock-Bundle не используется:
@BeforeClass
public static void setup() {
ClassLoader savedClassLoader = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(WireMockClassRule.class.getClassLoader());
wireMockServer = new WireMockServer(options().dynamicPort());
wireMockServer.start();
} finally {
Thread.currentThread().setContextClassLoader(savedClassLoader);
}
}
@AfterClass
public static void end() {
wireMockServer.stop();
}
Вы можете поместить этов JUnit @ClassRule
для инкапсуляции.