dbmock should not use a fixed temp directory

[bruno]

Currently dbmock uses a fixed (though configurable) temp directory for managing its data:

System.getProperty("java.io.tmpdir") + File.separator + ("dbmock")

(if I'm not mistaken) This means that if there are multiple instances of dbmock in use (in the same module, in different modules, or in different kauri instances) that they will all write to this directory, which will likely cause conflicts and confusion.

Suggestion: generate a unique directory name, e.g. dbmock-{number}, where number is a random number tried in a loop until it succeeds. To avoid too much of these directories in the temp dir, they should be deleted upon dbmock disposal (spring lifecycle), or using File.deleteOnExit (does this actually work for directories?).

[freya]

You can change this temporary location by adding the location to as third argument in the spring configuration of your project:

<bean id="data" class="org.kauriproject.dbmock.MockFinder?">

<constructor-arg ref="restletContext"/>
<constructor-arg ref="module"/>
<constructor-arg value="D:
tmp
dbmock
contactmodule"/>

</bean>

This third argument is optional, if you don't add it the temporary directory will be the default.

[mpo]

First reaction: It could still be useful to generate a numbered-directory when the 3rd constructor argument is not provided.

On second thought though: we have a mvn goal to copy over the mockdata to that directory, so it can't be just created randomly at run-time.

And just for completeness:

As a trick for generating temp-directories one can use the built in java feature to allocate a numbered temp-file through f=File.createTempFile(...), then do f.delete() and f.mkdir().

See also discussion on ​http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4735419 and beware of possible race conditions.

According to some comment there the deleteOnExit should work for directories as well. I'm just not sure that it will still if the directory is not empty. Might be wise to test and be sure.

[bruno]

@Freya: just fyi: I did a bit of work on MockFinder? yesterday, see this commit:
​http://kauriproject.org/issues/changeset/768
which makes that it is now the fourth argument.

@mpo: the copying of the mockdata is already done by the MockFinder? component itself.

I'm actually aware of all these possibilities, but it's just that I, as user, don't care where dbmock stores its data. For all I care, it could be managed in-memory rather than on disk (though being able to look on disk can help understanding/debugging). But I do not want to have to manage the locations myself just to avoid conflicts when using multiple instances of this component.

[bruno]

dbmock now uses a random generated temp dir name.