I think I understand why the default hostname and port number were made public now
The problem is that when you change to a client setup from an embedded setup, you basically have no values to supply to the TestConfiguration constructor. You can't use the values from the embedded setup, because they are 'null' and -1. You definitely don't want to supply your own custom values, as this will (possibly) mess up concurrent runs (for instance two suites.All on the same machine).
I had a brief discussion offline with Dag, and we identified the following scenarios wrt port numbers:
1) The default Derby port number (1527)
2) The default port number for the test run/configuration (as 1, or as specified by user by a property)
3) A different port for running multiple servers in the same test (typically as 2 with an offset)
Making the default Derby hostname and port public is not the right solution, as this will make independent runs always use the same hostname/port and could cause collision. Thus supporting only 1 is not a good solution.
By supporting option 2, and giving the user the possibility to override the port number used by the tests, we allow independent test runs to execute in parallel on a single machine. There are various implementation details here as well, such as if the property should only be read when the TestConfiguration class is loaded (static initializer block) or on instantiation. I prefer the first, as the second can lead to strange failures if the port number is changed "on-the-fly".
Option 3 is just a little extra, but as I don't think there is any use for it yet (??), it can be left for later. It certainly require more thought to avoid port usage to get out of control...
I have a few ideas for fixing this, but I need some more time with the initial patch.
If people have comments on this issue, please put them forth so they can be discussed and/or incorporated in the patch.
Note that there is a big difference between concurrent independent runs and parallelizing the execution of the tests. In the latter you run tests in parallel by invoking a single command and let the "harness" manage parallel execution. This demands more elaborate port handling, and I have not registered any community initiatives to implement parallel test execution.
I think I understand why the default hostname and port number were made public now
The problem is that when you change to a client setup from an embedded setup, you basically have no values to supply to the TestConfiguration constructor. You can't use the values from the embedded setup, because they are 'null' and -1. You definitely don't want to supply your own custom values, as this will (possibly) mess up concurrent runs (for instance two suites.All on the same machine).
I had a brief discussion offline with Dag, and we identified the following scenarios wrt port numbers:
1) The default Derby port number (1527)
2) The default port number for the test run/configuration (as 1, or as specified by user by a property)
3) A different port for running multiple servers in the same test (typically as 2 with an offset)
Making the default Derby hostname and port public is not the right solution, as this will make independent runs always use the same hostname/port and could cause collision. Thus supporting only 1 is not a good solution.
By supporting option 2, and giving the user the possibility to override the port number used by the tests, we allow independent test runs to execute in parallel on a single machine. There are various implementation details here as well, such as if the property should only be read when the TestConfiguration class is loaded (static initializer block) or on instantiation. I prefer the first, as the second can lead to strange failures if the port number is changed "on-the-fly".
Option 3 is just a little extra, but as I don't think there is any use for it yet (??), it can be left for later. It certainly require more thought to avoid port usage to get out of control...
I have a few ideas for fixing this, but I need some more time with the initial patch.
If people have comments on this issue, please put them forth so they can be discussed and/or incorporated in the patch.
Note that there is a big difference between concurrent independent runs and parallelizing the execution of the tests. In the latter you run tests in parallel by invoking a single command and let the "harness" manage parallel execution. This demands more elaborate port handling, and I have not registered any community initiatives to implement parallel test execution.