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: Running JUnit tests when derby.system.home does not exist
Date Fri, 27 Oct 2006 00:41:14 GMT
On 10/26/06, Kristian Waagan <Kristian.Waagan@sun.com> wrote:
> 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 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

Mime
View raw message