Maven Surefire

System properties set on the command line get clobbered

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.0 (2.2 plugin)
  • Fix Version/s: 2.6
  • Component/s: None
  • Labels:
    None
  • Environment:
    Linux, Maven 2.0.4, Sun JDK 1.5U5, bash 3.0
  • Number of attachments :
    1

Description

Some system properties get clobbered if you set them on the command line. For example,

mvn clean test -Dtest=LoginTest -Dselenium.user=test32

The 'test' system property will work, but the 'selenium.user' property will be null at runtime. I have tried:

  • hard coding the system property in the unit test, this worked fine.
  • setting the system properties in the pom file, this worked fine also.
  • tried an older version of the surefire plugin, this worked fine.

Issue Links

This issue is duplicated by:
SUREFIRE-564 [surefire] Command line parms not passed to tests on linux Major Closed
This issue relates to:
SUREFIRE-635 System properties are not reported in xml files Minor Closed
This issue is related to:
SUREFIRE-491 All system properties from Maven process are copied to forked Surefire process Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dan Fabulich added a comment -

Fixed in revision 598217.

Show
Dan Fabulich added a comment - Fixed in revision 598217.
Hide
Permalink
Milos Kleint added a comment -

This seriously breaks embedded usage. See this email sent to mevenide's mailing list:

It looks like, although my tests are configured to use either
forkMode=once or forkMode=perTest, Mevenide and/or the
maven-surefire-plugin in 2.4 either do not fork or (most probably) start
these new JVMs by explicitly (and incorrectly) passing all the system
properties and property values of the currently running JVM (i.e. the
JVM running the Netbeans IDE).

This means these system properties have "interesting" values when the
JUnit test code is running, like e.g.:

javax.xml.parsers.DocumentBuilderFactory=org.netbeans.core.startup.DOMFactoryImpl
javax.xml.parsers.SAXParserFactory=org.netbeans.core.startup.SAXFactoryImpl

As these NetBeans factory classes are not available from my project's
Meven test classpath, all my XML-related tests do now fail.

In addition, I get a message about a missing Logger configuration class:

Logging configuration class "org.netbeans.core.startup.TopLogging" failed
java.lang.ClassNotFoundException: org.netbeans.core.startup.TopLogging
–

Show
Milos Kleint added a comment - This seriously breaks embedded usage. See this email sent to mevenide's mailing list:
It looks like, although my tests are configured to use either forkMode=once or forkMode=perTest, Mevenide and/or the maven-surefire-plugin in 2.4 either do not fork or (most probably) start these new JVMs by explicitly (and incorrectly) passing all the system properties and property values of the currently running JVM (i.e. the JVM running the Netbeans IDE). This means these system properties have "interesting" values when the JUnit test code is running, like e.g.: javax.xml.parsers.DocumentBuilderFactory=org.netbeans.core.startup.DOMFactoryImpl javax.xml.parsers.SAXParserFactory=org.netbeans.core.startup.SAXFactoryImpl As these NetBeans factory classes are not available from my project's Meven test classpath, all my XML-related tests do now fail. In addition, I get a message about a missing Logger configuration class: Logging configuration class "org.netbeans.core.startup.TopLogging" failed java.lang.ClassNotFoundException: org.netbeans.core.startup.TopLogging –
Hide
Permalink
Milos Kleint added a comment -

MavenSession.getExecutionProperties() shall be the preferred call to System.getProperties()

Show
Milos Kleint added a comment - MavenSession.getExecutionProperties() shall be the preferred call to System.getProperties()
Hide
Permalink
Milos Kleint added a comment -

I believe pushing the System.getProperties() to a forked process is wrong generally.

"java.library.path", "java.class.path" and all JVM properties will be pushed from the maven process to the forked one, possibly polluting it, especially when the forked process is to be executed with a different JVM instance.

Show
Milos Kleint added a comment - I believe pushing the System.getProperties() to a forked process is wrong generally. "java.library.path", "java.class.path" and all JVM properties will be pushed from the maven process to the forked one, possibly polluting it, especially when the forked process is to be executed with a different JVM instance.
Hide
Permalink
Milos Kleint added a comment -

fixed the embedded use problem.
http://svn.apache.org/viewvc?rev=613539&view=rev

Show
Milos Kleint added a comment - fixed the embedded use problem. http://svn.apache.org/viewvc?rev=613539&view=rev
Hide
Permalink
Dan Fabulich added a comment -

This hotfix switches from using System.getProperties to using MavenSession.getExecutionProperties. MavenSession has no JavaDoc (or documentation of any kind?) so it's hard for me to tell how this hotfix works. What sort of properties get into executionProperties? What properties don't get into executionProperties?

http://maven.apache.org/ref/2.0.8/maven-core/apidocs/org/apache/maven/execution/MavenSession.html

Show
Dan Fabulich added a comment - This hotfix switches from using System.getProperties to using MavenSession.getExecutionProperties. MavenSession has no JavaDoc (or documentation of any kind?) so it's hard for me to tell how this hotfix works. What sort of properties get into executionProperties? What properties don't get into executionProperties? http://maven.apache.org/ref/2.0.8/maven-core/apidocs/org/apache/maven/execution/MavenSession.html
Hide
Permalink
Milos Kleint added a comment -

Unfortunately most components/classes in Maven have no javadoc, MavenSession is no exception. Since the instance can be retrieved via the ${session} expression in mojos, it makes it part of the official APIs to me though. Other can have more insight on the status of the class..

Currently the command line maven put all System.getProperties() there plus any props that were added on the command line.
Embedders can choose to provide same set or limit it. (eg. in my case I now filter out any netbeans-related properties in System.getproperties() list to prevent XML parser failures)

Show
Milos Kleint added a comment - Unfortunately most components/classes in Maven have no javadoc, MavenSession is no exception. Since the instance can be retrieved via the ${session} expression in mojos, it makes it part of the official APIs to me though. Other can have more insight on the status of the class.. Currently the command line maven put all System.getProperties() there plus any props that were added on the command line. Embedders can choose to provide same set or limit it. (eg. in my case I now filter out any netbeans-related properties in System.getproperties() list to prevent XML parser failures)
Hide
Permalink
Dan Fabulich added a comment -

Deliberately broken in revision 652773 to fix SUREFIRE-491.

Show
Dan Fabulich added a comment - Deliberately broken in revision 652773 to fix SUREFIRE-491.
Hide
Permalink
Christian Nelson added a comment -

Just Confirming... with maven 2.0.9 and 2.0.10-RC11, properties set on the command line are not passed to unit tests run by surefire 2.4.3. v2.4.2 passes the system properties.

For example:

mvn install -Djdbc.host=192.168.2.100

With v2.4.2, System.getProperty("jdbc.host") returns 192.168.2.100. With v.2.4.3 it returns null.

We rely on this behavior in unit tests frequently, sometime via System.getProperty() and other times indirectly through the use of Spring's PropertyPlaceholderConfigurer in SYSTEM_PROPERTIES_MODE_OVERRIDEmode.

Is the plan to revert back to the 2.4.2 behavior?

Show
Christian Nelson added a comment - Just Confirming... with maven 2.0.9 and 2.0.10-RC11, properties set on the command line are not passed to unit tests run by surefire 2.4.3. v2.4.2 passes the system properties. For example:
mvn install -Djdbc.host=192.168.2.100
With v2.4.2, System.getProperty("jdbc.host") returns 192.168.2.100. With v.2.4.3 it returns null. We rely on this behavior in unit tests frequently, sometime via System.getProperty() and other times indirectly through the use of Spring's PropertyPlaceholderConfigurer in SYSTEM_PROPERTIES_MODE_OVERRIDEmode. Is the plan to revert back to the 2.4.2 behavior?
Hide
Permalink
Gin-Ting Chen added a comment - - edited

I'm also interested in what happens in this bug.

2 potential solutions.

  1. just toggle between the two behaviors based on a <useSystemProperties>true</useSystemProperties> flag
  2. allow the use of a surefire.properties file with content like: 
    foobar=${foobar}

Why properties file support for setting properties was removed for m2 I could never understand but it would be a nice quick way to solve this particular problem.

Note: This bug also breaks using profile properties which is a real PITA.

Show
Gin-Ting Chen added a comment - - edited I'm also interested in what happens in this bug. 2 potential solutions.
  1. just toggle between the two behaviors based on a <useSystemProperties>true</useSystemProperties> flag
  2. allow the use of a surefire.properties file with content like: 
    foobar=${foobar}
Why properties file support for setting properties was removed for m2 I could never understand but it would be a nice quick way to solve this particular problem. Note: This bug also breaks using profile properties which is a real PITA.
Hide
Permalink
Chico Charlesworth added a comment -

This bug is preventing us from using 2.4.3, as we're running our tests behind a proxy, i.e. ('mvn test -Dhttp.proxyHost=<proxyHost> -Dhttp.proxyPort=<proxyPort>), and the system properties http.proxyHost and http.proxyPort are being passed in as null. With 2.4.2, it works fine.

Can someone say when we can expect this to be resolved? Or if there's another workaround for the time being?

Show
Chico Charlesworth added a comment - This bug is preventing us from using 2.4.3, as we're running our tests behind a proxy, i.e. ('mvn test -Dhttp.proxyHost=<proxyHost> -Dhttp.proxyPort=<proxyPort>), and the system properties http.proxyHost and http.proxyPort are being passed in as null. With 2.4.2, it works fine. Can someone say when we can expect this to be resolved? Or if there's another workaround for the time being?
Hide
Permalink
Dan Tran added a comment -

maven 2.1-M1 may have fixed it, could someone confirm?

Show
Dan Tran added a comment - maven 2.1-M1 may have fixed it, could someone confirm?
Hide
Permalink
Dan Tran added a comment -

btw, could some one provide a small pom to prove it?

Show
Dan Tran added a comment - btw, could some one provide a small pom to prove it?
Hide
Permalink
Dan Tran added a comment -

I think I have a work around, may be cumbersome for some ppl

http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/system-properties/pom.xml

note the pom use the new systemPropertyVariables, the deprecated one systemProperties still work

Show
Dan Tran added a comment - I think I have a work around, may be cumbersome for some ppl http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/system-properties/pom.xml note the pom use the new systemPropertyVariables, the deprecated one systemProperties still work
Hide
Permalink
Stefano Fornari added a comment -

Adding a simple project to reproduce the issue

Show
Stefano Fornari added a comment - Adding a simple project to reproduce the issue
Hide
Permalink
sridhar added a comment - - edited

Any workaround on this issue? i'm encountering same problem and at a loss of how to proceed.

if i use 2.4.2, then i get

java.lang.ClassNotFoundException: org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite

Show
sridhar added a comment - - edited Any workaround on this issue? i'm encountering same problem and at a loss of how to proceed. if i use 2.4.2, then i get java.lang.ClassNotFoundException: org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite
Hide
Permalink
Frédéric Camblor added a comment -

+1
In a Test framework we've made, we're executing tests in eclipse by building maven.

The test framework allow to pass system properties in order to "filter" executed test by "categories"
Example :
mvn test -Dtest.categories=non-regression
(that will only execute non regression tests during maven test phase "a la" TestNG)

Since maven 2.0.10 (which aligned with surfire 2.4.3) we no longer can use this functionnality ...

Only workarounds for us is either :

  • keep maven 2.0.9 (but this is crappy !!)
  • use explicitely surefire 2.4.2 (impacts on most of our poms)
  • define hacks in the poms, such as :
    <plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>${surefire.version}</version>
    <configuration>
    <systemProperties>
    <test.categories>${test.categories}</test.categories>
    </systemProperties>
    </configuration>
    </plugin>
    (impacts on most of our poms, too)

This is really crappy !!!

Show
Frédéric Camblor added a comment - +1 In a Test framework we've made, we're executing tests in eclipse by building maven. The test framework allow to pass system properties in order to "filter" executed test by "categories" Example : mvn test -Dtest.categories=non-regression (that will only execute non regression tests during maven test phase "a la" TestNG) Since maven 2.0.10 (which aligned with surfire 2.4.3) we no longer can use this functionnality ... Only workarounds for us is either :
  • keep maven 2.0.9 (but this is crappy !!)
  • use explicitely surefire 2.4.2 (impacts on most of our poms)
  • define hacks in the poms, such as : <plugin> <artifactId>maven-surefire-plugin</artifactId> <version>${surefire.version}</version> <configuration> <systemProperties> <test.categories>${test.categories}</test.categories> </systemProperties> </configuration> </plugin> (impacts on most of our poms, too)
This is really crappy !!!
Hide
Permalink
Jose Negreira added a comment -

Hi all, I've tried a cleaner workaround:

This was the not working property:
mvn test -Dtest=myTest -DserverUrl=foobar
serverUrl comes null.

And this is the working property using -DargLine:
mvn test -Dtest=myTest -DargLine=-DsomeUrl=foobar
serverUrl has 'foobar' value

for more than 1 parameter:
mvn test -Dtest=myTest -DargLine="-DsomeUrl=foobar -DotherParam=otherValue"

Credits for this go to Maximiliano Vazquez. (Thanks!)

HTH

Jose Negreira

Show
Jose Negreira added a comment - Hi all, I've tried a cleaner workaround: This was the not working property: mvn test -Dtest=myTest -DserverUrl=foobar serverUrl comes null. And this is the working property using -DargLine: mvn test -Dtest=myTest -DargLine=-DsomeUrl=foobar serverUrl has 'foobar' value for more than 1 parameter: mvn test -Dtest=myTest -DargLine="-DsomeUrl=foobar -DotherParam=otherValue" Credits for this go to Maximiliano Vazquez. (Thanks!) HTH Jose Negreira
Hide
Permalink
Benjamin Bentmann added a comment -

Fixed in r981279 by selectively propagating only those system properties to the tests that have been set by the user on the Maven command line via -Dkey=value, system props passed directly into the JVM via MAVEN_OPTS are not forwarded to the tests.

For this actually to work, Maven 2.1.0 or newer is required. For Maven 2.0.x, no system properties are propagated as in previous plugin versions and a warning is emitted.

Show
Benjamin Bentmann added a comment - Fixed in r981279 by selectively propagating only those system properties to the tests that have been set by the user on the Maven command line via -Dkey=value, system props passed directly into the JVM via MAVEN_OPTS are not forwarded to the tests. For this actually to work, Maven 2.1.0 or newer is required. For Maven 2.0.x, no system properties are propagated as in previous plugin versions and a warning is emitted.

People

Vote (22)
Watch (27)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.