After some (re)experimenting and dabbing in the permissions I am revisiting this...
As I understand it, there is no way (would violate some basic security concepts) for the networkserver to drop databases, or create subdirectories. (correct?)
Thus, when running against a networkserver on another system/IP address, all databases get created where the networkserver is running (possibly redirected, but it is still a fixed location). Thus databases are reused. In this, it is *like* running with useprocess false.
And yes, alas, this means a horrible mess catching up because test changes leave stuff behind. Thus, as I said in email to the list in December, I tried to make tests pass with useprocess=false as much as possible.
I think, also, that when I first ran with useprocess=false, various security permissions error went away, and I thought that I was doing the right thing. However, after I saw the securitymanager/useprocess=false checkin, I became suspicious of that conclusion, and thus I had to revisit. I felt it was my responsibility rather than simply complain.
I apologize for providing inaccurate information in my first reply on this thread, I hadn't thought it all through, and had forgotten some of the behaviour I had seen while experimenting in the month or so between my initial check-in and the question starting this thread. So, no, there is no problem on the serverside with permissions or creation of databases. Rather, there were problems because of reusing of databases and security trouble on the clientside.
The clientside securitymanager troubles are essentially resolved by making the hostName test property automatically getting passed into the ${derbyTesting.serverhost} (renamed from $csinfo.serverhost) property in jvm.java
which resolves the property in derby_tests.policy. (I did this in my inital patch for DERBY-871).
Now, I would still like to pursue the useprocess=false angle a little.
In my thinking, it would kill 2 birds with one stone - speed up processing and make every developer responsible for cleaning up their tests instead of putting that burden on myself or whomever actually tries to test with remote host. In theory everyone *should* cleanup the tests objects they create anyways, so I didn't think it an unreasonable hardship. As you might have noticed, I did take it on to get things a fair ways.
I had jdbc20 suite almost running with useprocess=false...except for
- jdbcapi/getCurConnJdbc20.java when running with db2jcc in the classpath.
It hits:
ERROR XJ001: Java exception: 'access denied ( java.lang.RuntimePermission loadLibrary.db2jcct2): java.security.AccessControlException'
(as I reported to the list).
I think this problem will be resolved by granting db2jcc*.jar all. I haven't tested this. But would it be ok? Is there a better approach?
- all tests run with either JCC or with test property securityManager=false after an initial test has securityManager installed fail because the message 'security Manager not installed' pops up in the test output, instead of the *.sum (or to the console).
This is because it gets generated after the redirection to the stream (from calling the method installManager.
I understand from Dan's reply in this thread and re DERBY-871 that this was because otherwise additional permissions would be needed. I never saw errors relating to the stream, but then I was running with the classes - could that make a difference? What would be the behavio(u)r if you'd get the permission error? Maybe I saw it and misunderstood...
- still...would it be possible to save the installedSecurityManager state and set things back for every test, i.e. uninstall security Manager somehow? Would that be a slowing down things?
Myrna
