When making a change to the Network Server code, it is useful to be able to verify that the change does not break old clients. Here is one technique you can use:

There may be diffs when you do this, related to changes to the new release which are known to cause compatibility problems with the previous client code. If you have trouble understanding the diffs, post a message to the developers list and some of the other Derby developers will be glad to help you interpret the diffs.

Jar file location and security policy

Note that the security policy file grants permissions to read all property for derbytesting.jar in both 10.1 and 10.2, so ideally access to properties should work for code from both sets of jars. However, if you leave the jars in separate directories, and simply update your classpath to refer to 10.1 jars in one location and 10.2 jars in another location, that won't work in our harness.

The symptom is that you will see test differences referring to permission denied errors.

For example, suppose the 10.2 derby.jar and derbynet.jar were before any of the other jars. When you run the test, it sets the 'csinfo.codejar' as the location for the jar files and the derby_tests.policy file expects that the 10.1 derbyTesting.jar and derbytools.jar etc are all in the same directory as derbynet.jar. But it picked up the csinfo.codejar as the location where the 10.2 derbynet.jar was and thus the policy file was not granting permission to your 10.1 jars that were in the classpath and hence the exception.

To fix this, the simplest technique is to place the 10.1 derbyclient.jar and 10.1 derbyTesting.jar in the same directory location where the other derbynet.jar and derby.jar are, and then permissions will be granted correctly and test passes.

TestingOldClientNewServer (last edited 2009-09-20 22:12:33 by localhost)