db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5791) Replication tests should use BaseTestCase.execJavaCmd() to run local commands
Date Tue, 29 May 2012 14:48:24 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-5791:

    Attachment: d5791-1a.diff

Attaching a patch that makes ReplicationRun use
BaseTestCase.execJavaCmd() to run local commands. The patch is built
on top of the patch for DERBY-5783, so it can't be committed until
that patch has been checked in.

The patch rearranges the code so that Runtime.exec() is only called
two places in the code (one for remote processes, and one for local
processes), and replaces the call that creates the local processes
with a call to BaseTestCase.execJavaCmd().

The replication tests passed with the patch. Running the full
regression test suite now.

More details:

* junit/BaseTestCase.java

- Overloaded execJavaCmd() with a variant that allows specifying the
  working directory.

* functionTests/tests/replicationTests/Utils.java

- Added helper methods toStringArray() and splice() to replace some
  repeated operations in ReplicationRun.

- Removed unused method NIOcopy.

* functionTests/tests/replicationTests/ReplicationRun.java

- Moved body of runUserCommand() method into runUserCommandLocally()
  to make it clearer that it was never used for remote processes.

- Renamed runUserCommandInThread() runUserCommandInThreadLocally() to
  make it clearer that it was only for local processes, and to make
  method naming consistent with that of the methods that start remote

- Made runUserCommandInThreadLocally() and
  runUserCommandInThreadRemotely() wrap runUserCommandLocally() and
  runUserCommandRemotely(), respectively, to reduce the number of
  places that call exec(), and to reduce the total amount of code.

- Made startServer() call runUserCommandInThreadLocally() and
  runUserCommandInThreadRemotely() instead of calling exec() directly,
  and made stopServer() call runUserCommandLocally() and
  runUserCommandRemotely() for the same reason.

- Changed signatures of runUserCommand[InThread]Locally() to take the
  command as an array instead of a flat string, so that it could
  easily be passed on to BaseTestCase.execJavaCmd().

- Made runUserCommandLocally() call BaseTestCase.execJavaCmd().
> Replication tests should use BaseTestCase.execJavaCmd() to run local commands
> -----------------------------------------------------------------------------
>                 Key: DERBY-5791
>                 URL: https://issues.apache.org/jira/browse/DERBY-5791
>             Project: Derby
>          Issue Type: Improvement
>          Components: Test
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: d5791-1a.diff
> The replication tests invoke Runtime.exec() directly in order to spawn processes. The
sub-processes that run on the same host as the main test process, should instead be started
with the helper method BaseTestCase.execJavaCmd(). Having all the tests use the helper method
would make it easier if we for example want to pass specific flags to all sub-processes created
in a test run.
> Note that the replication tests also have code for starting processes on a remote host
via ssh. BaseTestCase.execJavaCmd() cannot do that, so only local processes can be started
with the helper method. When the replication tests run as part of suites.All, all the spawned
processes run locally.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message