Системные свойства не могут быть разрешены в Spring XML с помощью Maven - PullRequest
2 голосов
/ 28 октября 2009

Мое приложение должно знать путь к каталогу, в котором оно может хранить свои данные. Я попытался установить системное свойство Java и использовать эту переменную в качестве заполнителя в моем Spring XML.

В Eclipse я добавил это свойство в среду моей конфигурации запуска, и оно работает просто отлично. Spring преобразует $ {dataDir} в правильный путь.

Но когда я тестирую приложение с помощью Maven2 ( mvn test -DdataDir = c: / data ), Spring жалуется, что не может разрешить заполнитель.

Мой Spring XML выглядит так:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"

 xmlns:tx="http://www.springframework.org/schema/tx"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans.xsd
      http://www.springframework.org/schema/tx
      http://www.springframework.org/schema/tx/spring-tx.xsd">

 <!-- Allows me to use system properties in this file -->
 <bean id="propertyPlaceholderConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer" />

 <bean id="xmlConfiguration" class="org.apache.commons.configuration.XMLConfiguration">
  <constructor-arg index="0">
   <value>${dataDir}/conf/config.xml</value>
  </constructor-arg>
 </bean>
</beans>

Почему это системное свойство не передается в Spring? Что я делаю неправильно? Спасибо за любые предложения!

РЕДАКТИРОВАТЬ: Конечно, вы правы: $ {baseDir} должен быть $ {dataDir}. Но это была просто опечатка в этом вопросе, а не в реальном коде.

Я пытался MAVEN_OPTS и раньше, но это тоже не работает ...

Ответы [ 5 ]

4 голосов
/ 29 октября 2009

Это известная ошибка в плагине Surefire 2.4.3. Для получения дополнительной информации см. Вопрос JIRA " Системные свойства, заданные в командной строке, получают ". Используйте предыдущую версию 2.4.2 вместо:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <!-- Use 2.4.2 because 2.4.3 has bug with system properties
           see http://jira.codehaus.org/browse/SUREFIRE-121 -->
      <version>2.4.2</version>
    </plugin>
  </plugins>
</build>
1 голос
/ 28 октября 2009

Возможно, mvn test не проходит через системные свойства, с которыми он запускается в тестах? Можно ли передать свойства с помощью тестового плагина (который сам по себе может извлечь их из свойств системы)?

Смотри также: http://maven.apache.org/maven-1.x/plugins/test/properties.html

0 голосов
/ 31 октября 2009

Я думаю, что ответ Фликкена - правильный ответ на ваш вопрос.

Однако я бы предложил переместить файл config.xml в src/test/resources. Кажется, это идеальное место (в мире maven), и, таким образом, файл будет доступен на пути к классам (поэтому вам не нужно будет использовать абсолютный путь). Кроме того, файл попадет в систему управления версиями, как и любой другой ресурс проекта, и это хорошо.

Если вы действительно хотите оставить его вне структуры проекта, я бы использовал фильтрацию ресурсов , чтобы отфильтровать ваш файл конфигурации Spring и установить ${dataDir} во время сборки.

0 голосов
/ 28 октября 2009

Может быть, вы должны использовать одинаковые имена переменных? Я имею в виду, что вы передаете dataDir, но ожидаете baseDir. Я не прав?

0 голосов
/ 28 октября 2009

Если вы посмотрите на сценарий mvn, вы увидите, что все аргументы, передаваемые через командную строку, передаются как аргументы классу запуска, а не как аргументы JVM. Так что -D не будет работать.

Самый быстрый обходной путь - определить переменную окружения MAVEN_OPTS, например,

set MAVEN_OPTS="-DdataDir=c:/data"

, а затем запустить mvn test

...