2013-11-21 2 views
2

Я сделал уже довольно некоторое исследование в Интернете по этой проблеме. Мне пока не повезло. В основном этот кусок кода отлично работает на Windows, с моей JUnit тест Src \ Test \ Java \ COM \ проекта \ Utils \ MyTestCase.java:FileNotFoundException на машине linux при использовании getClassLoader(). GetResource

URL urlApplicationContext = this.getClass().getClassLoader().getResource("applicationContext.xml"); 
final String[] paths = { urlApplicationContext.getFile()}; 
ApplicationContext ctx = new FileSystemXmlApplicationContext(paths); 

Этот файл находится там:

\ SRC \ тест \ ресурсы \ applicationContext.xml

Однако на машине Дженкинс, которая запускается на Linux, я получил следующее сообщение об ошибке:

testSimple (com.project.ClientImplTest): IOException синтаксического анализа XML из файла [/data/continuous/workspace/sonar/main_proj/data/continuous/workspace/sonar/main_proj/target/main/WEB-INF/test-classes/applicationContext.xml]; вложенной исключение составляет java.io.FileNotFoundException: данных/непрерывная/рабочее пространство/сонар/main_proj/цель/основные/WEB-INF/тест-классы/applicationContext.xml (Нет такого файла или каталога)

Я уже подтвердил, что файл /data/continuous/workspace/sonar/main_proj/target/main/WEB-INF/test-classes/applicationContext.xml существует.

Почему getResource() не нашел правильный путь в Linux. Кажется, он находит данные/непрерывный/... вместо/data/continous/... по какой-то причине? Поэтому FileSystemXmlApplicationContext может возвращать исключение, потому что он не может найти файл.

Благодаря

ответ

1

Попробуйте добавить отладочный вывод. URL имеет хороший метод toString(). Таким образом, вы получите, где приложение ищет файл.

Похоже, вы пропустили слэш в самом начале. Замените data/continuous/... на /data/continuous/... на свой ресурсный загрузчик.

+0

Привет, Каким методом загрузки ressource является this.getClass(). GetClassLoader(). GetResource ("applicationContext-hibernate-junit.xml"). Путь на Linux-машине выполняется динамически. Я не знаю, что вы подразумеваете под «загрузчиком ресурсов»? –

+0

'getResource' дает вам только URL-адрес. Затем вы загружаете xml по url и получаете исключение, потому что проскальзывание пропущено => путь неверен. Метод, в котором вы загружаете этот xml, я называл загрузчиком ресурсов. Если этот метод находится внутри Дженкинса, возможно, вы используете его неправильно. –

+0

try: 1) System.out.println (urlApplicationContext); 2) ctx = new FileSystemXmlApplicationContext ("target/main/WEB-INF/test-classes/applicationContext.xml"); –

0

На самом деле Дженкинс не жалующийся файл applicationContext.xml, но это один: data/continuous/workspace/sonar/main_proj/target/main/WEB-INF/test-classes/applicationContext-hibernate-junit.xml

+0

В исходном посте была плохая копия. Дженкинс жалуется на applicationContext.xml. Я изменил сообщение. –

0

Почему getResource() не найти правильный путь на Linux.

Я думаю, вам нужно снова взглянуть на ваш код и stacktraces.

Метод getResource() не выбрасывает IOException или любые подклассы IOException. Никогда не.

Исключением, которое вы видите, бросает ... что-то еще. И из сообщения ясно видно, что код, который генерирует это исключение, не является , смотрящим на файл под названием «applicationContext.xml».

UPDATE

Даже после вашей коррекции, остается incontravertable факта, что getResource() не может вызвать FileNotFoundException. Вы смотрите на неправильный код.

3

У меня была такая же проблема в моем проекте - это было вызвано пробелами в пути - обрабатывать такие случаи, вы должны использовать URL-адрес в Touri() метод - сделайте следующее:

ApplicationContext ctx; 
URL urlApplicationContext = this.getClass().getClassLoader().getResource("applicationContext.xml"); 
if (urlApplicationContext != null) { 
    File appCtxFile = new File(urlApplicationContext.toURI()); 
    ctx = new FileSystemXmlApplicationContext(new String[]{ appCtxFile.getAbsolutePath() }); 
} else { 
    throw new RuntimeException("Cannot find XML file 'applicationContext.xml'"); 
} 
1

Так как у меня нет достаточного количества голосов, чтобы пересмотреть или прокомментировать или что-то скажу, что мне нужно сказать здесь lol

Oifan абсолютно прав (читайте, что нужно принять).

Был такой же вопрос о Дженкинсе. Код пытался получить доступ к файлу во время теста, у него были пробелы, в результате получилось FileNotFoundException. Файл определенно находится в нужном месте.

Мое тестирование также показало, что места были виновниками. Мы просто собирались переименовать проект в Jenkins, что привело бы к тому, что в нашей структуре каталогов не было бы больше пробелов. Затем я наткнулся на ответ Ойфана.

Преобразование URL от getResource() к URI и попутно, что в File() решить эту проблему для нас.

BTW, проблема не изолирована от linux. Я тоже видел это поведение у рабов Windows Jenkins.

Смежные вопросы