On 2/11/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
Myrna van Lunteren wrote:
> I could use some help on this one.
> The problem does *not* occur with jdk14, ibm15, jdk15.
> The problem only occurs with jars - I've been using insane jars.
>
> The reason I changed the database name was to enable this test to be run
> in the remote host configuration. In that setup, the test would be run
> after several other tests, and there were too many things left behind to
> get a clear result.
>
> I got past the java.security.AccessControlException by granting to
> derbynet.jar:
> permission java.io.FilePermission
> "${derby.system.home}${/}syscatdb${/}tmp${/}-", "read, write, delete";
>
> So, is this a jvm bug or another privileged block needed somewhere in
> derby code only accessed with ibm142?
>
> If privileged block, how does one find out where? (this may seem obvious
> to other people, or even to me at some other time. it's late, or,
> rather, early).
>
> Or is this the same issue as DERBY-616? That one doesn't say it's only
> with ibm142...
I think you are correct here, it looks like 616. Since this is most
likely an ORDER BY spilling to disk, it is environment dependent when
that occurs. It's probably that this test is on the border line for
spilling the sort to disk and only ibm142 crosses it.
I would just disable this test from running with the security manager
and mark it as due to DERBY-616.
Dan.
Well, that was one of the things that first puzzled me - Mike reported this with DerbyNet, and none of the DerbyNet tests actually run with security manager.
However, the network server seems to *always* start with security manager, even when the actual test has security manager switched off. I'll have a look at that also.
(pf).
In the mean time, would it be acceptable to add the permissions so the nightlies pass on?
Thx,
Myrna
