db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Running JUnit tests when derby.system.home does not exist
Date Thu, 26 Oct 2006 14:00:21 GMT
Myrna van Lunteren wrote:
> On 10/25/06, Kristian Waagan <Kristian.Waagan@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, 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.


> Myrna

View raw message