Вы используете интерфейс, но, похоже, вам нужен базовый класс. Интерфейс никогда не должен нуждаться в конструкторе, поскольку он не может содержать никаких полей, которые должны были бы быть инициализированы в конструкторе. Я думаю, что вы хотите использовать базовый класс вместо этого.
В дополнение к переопределению getConfigLocations я также переопределил loadContext и использовал там надежный fileSystemXmlApplicationContext.
@Override
protected String[] getConfigLocations() {
return new String[] { "WEB-INF/services-config.xml" };
}
@Override
protected ConfigurableApplicationContext loadContext(String[] locations) throws Exception {
return new FileSystemXmlApplicationContext(locations);
}
Мы помещаем все наши файлы конфигурации и свойств Spring в путь к классам, что упрощает работу - мы можем просто расширить наши тестовые классы из базового класса, например:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={
"/spring/*.xml",
"/testSpring/*.xml" })
public abstract class AbstractIntegrationTest {
Здесь пути все пути в classpath.
Если вы не хотите этого делать, проверяли ли вы, как вы ссылаетесь на файлы свойств в вашем services-context.xml? Я подозреваю, что если вы добавите file: в конфигурацию контекста, вам также нужно будет добавить это в ссылку на файл свойств. Возможно, вы могли бы просто использовать отдельный тестовый файл конфигурации Spring, чтобы изменить определение заполнителя вашего свойства, и поместить его в конец списка файлов контекста - его определения затем переопределят те, которые были определены в более ранних файлах.
Расположение ваших конфигураций - это относительные URI, которые будут интерпретироваться как таковые базовым тестовым классом, при этом URI разрешается относительно местоположения самого тестового класса. Попробуйте использовать полностью определенные URI или относительный URI с учетом того, где находится тестовый класс.
Разве нельзя использовать фабрики XML пути к классам, такие как ClassPathXmlApplicationContext ?