> don't have a suggestion for automated testing to check the derby.log
I'm just blue-sky thinking here, but here are some possible ideas:
1) Write some common shared utility code that uses java.io.* classes to
go find the derby.log file on disk and read it.
2) Inject some sort of "duplicate" or "tee" stream into the output routines
that write to derby.log so that they can be hooked to emit output both
to derby.log and to some other stream (say, an in-memory byte-array
stream) that can then be examined for the content in question.
3) Change the output routines that write to derby.log so that they have
some sort of "registered handler" concept so that, immediately prior
to writing some data to derby.log, they call back to any registered output
handlers to give the handler a chance to examine the data that's about
to be written.
One way to look at these options is whether the test hooks should examine
the derby.log output after-the-fact, as-the-data-is-being-written, or
Another way is whether the right abstraction layer is to consider the
file as a whole as a stream of data, or each individual "record" as it
is being written to the file.
And yet another way to look at the options is whether it's easiest to write
the test code as callback handlers, or as stream-content verifiers. How
will it be easiest to recognize the logging content that you're looking for?
Solutions (2) and (3) assume that the test code is in the same JVM as
the Derby code being tested, so they wouldn't work so well for network
server tests, although for this particular case that might be just fine.
Just thought I'd try to throw some ideas out there to encourage the discussion.