db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrna van Lunteren <m.v.lunte...@gmail.com>
Subject Re: testing using remote host
Date Tue, 31 Jan 2006 18:12:45 GMT
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



>
>

Mime
View raw message