Maven Surefire
  1. Maven Surefire
  2. SUREFIRE-121

System properties set on the command line get clobbered

    Details

    • Type: Bug Bug
    • Status: 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

      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.
      1. testargs.zip
        5 kB
        Stefano Fornari

        Issue Links

          Activity

          Hide
          Dan Fabulich added a comment -

          Fixed in revision 598217.

          Show
          Dan Fabulich added a comment - Fixed in revision 598217.
          Hide
          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
          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
          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
          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
          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
          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
          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
          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
          Tim 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
          Tim Chen added a comment - - edited I'm also interested in what happens in this bug. 2 potential solutions. just toggle between the two behaviors based on a <useSystemProperties>true</useSystemProperties> flag 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
          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
          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
          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
          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
          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
          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
          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
          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
          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

            • Assignee:
              Benjamin Bentmann
              Reporter:
              Brenton Leanhardt
            • Votes:
              22 Vote for this issue
              Watchers:
              23 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development