You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Kristian Waagan <Kr...@Sun.COM> on 2006/10/25 20:03:35 UTC
Running JUnit tests when derby.system.home does not exist
Hello,
I was running various JUnit tests/suites and the test
'jdbcapi.BlobClob4Blob' was failing with a security exception, but when
run as part of 'suites.All' it was not.
After some investigation, I discovered the following:
1) derby.system.home was set to a non-existing directory.
Set to `pwd`/system, see static initializer in TestConfiguration
2) When I ran the All suite, no security manager was installed.
I have not confirmed if this is true for all tests (it is probably
not), but no security manager was installed at the time when the
first setUp-method was run. I created DERBY-2000 to track this, and
also added a little more info.
Because of 2), creating derby.system.home worked when running the All
suite, but not when running the other test. What happens, is that the
directory is attempted created in 'impl.services.monitor.FileMonitor' if
it does not exists. When a SecurityException is raised, the
initialize-method returns false and the boot process is aborted. This
causes the line 'return getDriverModule().connect(...)' in
'jdbc.AutoloadedDriver' to throw a NPE (and this is what you get to see
when running the test).
I can think of two solutions to the directory creation problem:
a) Add write permissions to derby.system.home for derby.jar.
If this is done, the system would be able to create the directory,
and possibly overwrite derby.system.home if it happens to point to
a file (combination of user error and malicious/bad code in Derby),
but not delete it;
permission java.io.FilePermission "${derby.system.home}", "read,
write";
With the permission above, no permissions need to be granted to the
parent directory of derby.system.home.
b) Document that derby.system.home must point to an existing
directory when running JUnit tests.
I think a) seems most useful, especially in terms of user-friendliness.
On the other hand, you should know up front where the database store the
data, so option b) is not a disaster either.
Any opinions/questions?
--
Kristian
Re: Running JUnit tests when derby.system.home does not exist
Posted by Myrna van Lunteren <m....@gmail.com>.
On 10/26/06, Kristian Waagan <Kr...@sun.com> wrote:
> Myrna van Lunteren wrote:
> > On 10/25/06, Kristian Waagan <Kr...@sun.com> wrote:
> >> Hello,
> >>
> >> I was running various JUnit tests/suites and the test
> >> 'jdbcapi.BlobClob4Blob' was failing with a security exception, but when
> >> run as part of 'suites.All' it was not.
> >>
> >> After some investigation, I discovered the following:
> >> 1) derby.system.home was set to a non-existing directory.
> >> Set to `pwd`/system, see static initializer in TestConfiguration
> >>
> >> 2) When I ran the All suite, no security manager was installed.
> >> I have not confirmed if this is true for all tests (it is probably
> >> not), but no security manager was installed at the time when the
> >> first setUp-method was run. I created DERBY-2000 to track this, and
> >> also added a little more info.
> >>
> >> Because of 2), creating derby.system.home worked when running the All
> >> suite, but not when running the other test. What happens, is that the
> >> directory is attempted created in 'impl.services.monitor.FileMonitor' if
> >> it does not exists. When a SecurityException is raised, the
> >> initialize-method returns false and the boot process is aborted. This
> >> causes the line 'return getDriverModule().connect(...)' in
> >> 'jdbc.AutoloadedDriver' to throw a NPE (and this is what you get to see
> >> when running the test).
> >>
> >> I can think of two solutions to the directory creation problem:
> >> a) Add write permissions to derby.system.home for derby.jar.
> >> If this is done, the system would be able to create the directory,
> >> and possibly overwrite derby.system.home if it happens to point to
> >> a file (combination of user error and malicious/bad code in Derby),
> >> but not delete it;
> >> permission java.io.FilePermission "${derby.system.home}", "read,
> >> write";
> >>
> >> With the permission above, no permissions need to be granted to the
> >> parent directory of derby.system.home.
> >>
> >> b) Document that derby.system.home must point to an existing
> >> directory when running JUnit tests.
> >>
> >> I think a) seems most useful, especially in terms of user-friendliness.
> >> On the other hand, you should know up front where the database store the
> >> data, so option b) is not a disaster either.
> >>
> >> Any opinions/questions?
> >>
> >>
> >> --
> >> Kristian
> >>
> > Can't we put a stop in somewhere(where?), i.e. bail out if system.home
> > does not exist or is a file (rather than a directory)?
>
> Yes, we could do that, but is it what we want to happen?
> Basically, it is what happens today, you just get a nicer error message.
>
> The question then is whether we want the stop to happen in Derby
> (FileMonitor?), or in the test system. For deployment, it makes it
> easier to allow Derby to create derby.system.home if it has the
> permissions to do so and the path is indeed a directory.
>
> I tried specifying derby.system.home as a file with Derby 10.2.1.7, and
> the error message you get in ij is "No suitable driver" (because the
> engine is never booted and the driver not registered).
>
>
> If nobody has strong opinions, I'm thinking about writing a patch to
> improve the error handling and that still creates the directory if it is
> valid and allowed.
>
>
>
> --
> Kristian
>
> >
> > Myrna
>
>
+1
Myrna
Re: Running JUnit tests when derby.system.home does not exist
Posted by Kristian Waagan <Kr...@Sun.COM>.
Myrna van Lunteren wrote:
> On 10/25/06, Kristian Waagan <Kr...@sun.com> wrote:
>> Hello,
>>
>> I was running various JUnit tests/suites and the test
>> 'jdbcapi.BlobClob4Blob' was failing with a security exception, but when
>> run as part of 'suites.All' it was not.
>>
>> After some investigation, I discovered the following:
>> 1) derby.system.home was set to a non-existing directory.
>> Set to `pwd`/system, see static initializer in TestConfiguration
>>
>> 2) When I ran the All suite, no security manager was installed.
>> I have not confirmed if this is true for all tests (it is probably
>> not), but no security manager was installed at the time when the
>> first setUp-method was run. I created DERBY-2000 to track this, and
>> also added a little more info.
>>
>> Because of 2), creating derby.system.home worked when running the All
>> suite, but not when running the other test. What happens, is that the
>> directory is attempted created in 'impl.services.monitor.FileMonitor' if
>> it does not exists. When a SecurityException is raised, the
>> initialize-method returns false and the boot process is aborted. This
>> causes the line 'return getDriverModule().connect(...)' in
>> 'jdbc.AutoloadedDriver' to throw a NPE (and this is what you get to see
>> when running the test).
>>
>> I can think of two solutions to the directory creation problem:
>> a) Add write permissions to derby.system.home for derby.jar.
>> If this is done, the system would be able to create the directory,
>> and possibly overwrite derby.system.home if it happens to point to
>> a file (combination of user error and malicious/bad code in Derby),
>> but not delete it;
>> permission java.io.FilePermission "${derby.system.home}", "read,
>> write";
>>
>> With the permission above, no permissions need to be granted to the
>> parent directory of derby.system.home.
>>
>> b) Document that derby.system.home must point to an existing
>> directory when running JUnit tests.
>>
>> I think a) seems most useful, especially in terms of user-friendliness.
>> On the other hand, you should know up front where the database store the
>> data, so option b) is not a disaster either.
>>
>> Any opinions/questions?
>>
>>
>> --
>> Kristian
>>
> Can't we put a stop in somewhere(where?), i.e. bail out if system.home
> does not exist or is a file (rather than a directory)?
Yes, we could do that, but is it what we want to happen?
Basically, it is what happens today, you just get a nicer error message.
The question then is whether we want the stop to happen in Derby
(FileMonitor?), or in the test system. For deployment, it makes it
easier to allow Derby to create derby.system.home if it has the
permissions to do so and the path is indeed a directory.
I tried specifying derby.system.home as a file with Derby 10.2.1.7, and
the error message you get in ij is "No suitable driver" (because the
engine is never booted and the driver not registered).
If nobody has strong opinions, I'm thinking about writing a patch to
improve the error handling and that still creates the directory if it is
valid and allowed.
--
Kristian
>
> Myrna
Re: Running JUnit tests when derby.system.home does not exist
Posted by Myrna van Lunteren <m....@gmail.com>.
On 10/25/06, Kristian Waagan <Kr...@sun.com> wrote:
> Hello,
>
> I was running various JUnit tests/suites and the test
> 'jdbcapi.BlobClob4Blob' was failing with a security exception, but when
> run as part of 'suites.All' it was not.
>
> After some investigation, I discovered the following:
> 1) derby.system.home was set to a non-existing directory.
> Set to `pwd`/system, see static initializer in TestConfiguration
>
> 2) When I ran the All suite, no security manager was installed.
> I have not confirmed if this is true for all tests (it is probably
> not), but no security manager was installed at the time when the
> first setUp-method was run. I created DERBY-2000 to track this, and
> also added a little more info.
>
> Because of 2), creating derby.system.home worked when running the All
> suite, but not when running the other test. What happens, is that the
> directory is attempted created in 'impl.services.monitor.FileMonitor' if
> it does not exists. When a SecurityException is raised, the
> initialize-method returns false and the boot process is aborted. This
> causes the line 'return getDriverModule().connect(...)' in
> 'jdbc.AutoloadedDriver' to throw a NPE (and this is what you get to see
> when running the test).
>
> I can think of two solutions to the directory creation problem:
> a) Add write permissions to derby.system.home for derby.jar.
> If this is done, the system would be able to create the directory,
> and possibly overwrite derby.system.home if it happens to point to
> a file (combination of user error and malicious/bad code in Derby),
> but not delete it;
> permission java.io.FilePermission "${derby.system.home}", "read,
> write";
>
> With the permission above, no permissions need to be granted to the
> parent directory of derby.system.home.
>
> b) Document that derby.system.home must point to an existing
> directory when running JUnit tests.
>
> I think a) seems most useful, especially in terms of user-friendliness.
> On the other hand, you should know up front where the database store the
> data, so option b) is not a disaster either.
>
> Any opinions/questions?
>
>
> --
> Kristian
>
Can't we put a stop in somewhere(where?), i.e. bail out if system.home
does not exist or is a file (rather than a directory)?
Myrna