Daniel John Debrunner wrote:
- The server is booted without setting derby.system.home. For the vm
running the junit tests derby.system.home=${user.dir}/system. Since
d.s.h is not set the server is running with a system home of user.dir.
I think this explains the wombat database appearing in the current
directory when running junit tests. I'm not sure if this intended when
this decorator was added, the concept of the system folder was to have
all Derby databases beneath that folder. Of course if d.s.h is set to
${user.dir}/system for the spawned server then we have two jvms
accessing the same system and poentially the same databases. There are
three possible solutions to this:
a) Set d.s.h to ${user.dir}/system but shutdown Derby in the test
vm before starting the separate server.
b) Set d.s.h to ${user.dir}/ns (a different sub-folder) and ensure
tests wrapped in this decorator only use databases under d.s.h.
c) Leave it as-is, d.s.h defaults to ${user.dir} which leaves a
wombat in the current folder.
Wiki page on junit folders ...
http://wiki.apache.org/db-derby/DerbyJunitTestConfiguration?#head-af5a240fccda5c96f104776dfbd20a8cabde55e0
I think my vote goes to alternative b.
It would be good to not have any db's directly at ${user.dir}. Then you
would know it is a bug somewhere if you find one there and not just
assume it was created by a networkserver test. From the wiki page on
junit folders I also see an argument that putting db's in subfolders
allows more clear policyfiles.
I think having two vm's sharing the same subfolder has the potential of
causing problems that are hard to analyze if for some reason the Derby
in the test vm did not get shut down when a networkserver test runs, or
vice versa.
Vemund
