Derby/JUnit bad interaction - any ideas?
I've been trying to get some basic tests working under Junit. Unfortunately, I've run into a Derby problem which prevents these tests from working. What happens is this. Derby, when it creates a database, forces a number of directories within the database to read-only. Unfortunately, unless we stipulate Java 1.6 or up, there is no native Java way to make these directories become non-read-only. So database cleanup always fails to actually remove the old database, and then new database creation subsequently fails. So there are two possibilities. First, we can change things so we never actually try to clean up the Derby DB. Second, we can mandate the java 1.6 is used for LCF. That's all there really is. The first possibility is tricky but doable - I think. The second would probably be unacceptable in many ways. Thoughts? Karl
Re: Derby/JUnit bad interaction - any ideas?
On 6/8/10 6:35 AM, karl.wri...@nokia.com wrote: I've been trying to get some basic tests working under Junit. Unfortunately, I've run into a Derby problem which prevents these tests from working. What happens is this. Derby, when it creates a database, forces a number of directories within the database to read-only. Unfortunately, unless we stipulate Java 1.6 or up, there is no native Java way to make these directories become non-read-only. So database cleanup always fails to actually remove the old database, and then new database creation subsequently fails. So there are two possibilities. First, we can change things so we never actually try to clean up the Derby DB. Second, we can mandate the java 1.6 is used for LCF. That's all there really is. The first possibility is tricky but doable - I think. The second would probably be unacceptable in many ways. Thoughts? Karl Interesting - when I worked with derby in the past, I never had any trouble deleting a database after shutting it down on windows using Java 5. It worked great with my unit tests. You could always run each test in a new system tmp dir every time... I find it hard to believe you cannot delete the database somehow though - like I said, I never had any problems with it using embedded derby in the past after shutting down the db. -- - Mark http://www.lucidimagination.com
Re: Derby/JUnit bad interaction - any ideas?
(10/06/08 22:35), karl.wri...@nokia.com wrote: I've been trying to get some basic tests working under Junit. Unfortunately, I've run into a Derby problem which prevents these tests from working. What happens is this. Derby, when it creates a database, forces a number of directories within the database to read-only. Unfortunately, unless we stipulate Java 1.6 or up, there is no native Java way to make these directories become non-read-only. So database cleanup always fails to actually remove the old database, and then new database creation subsequently fails. So there are two possibilities. First, we can change things so we never actually try to clean up the Derby DB. Second, we can mandate the java 1.6 is used for LCF. That's all there really is. The first possibility is tricky but doable - I think. The second would probably be unacceptable in many ways. Thoughts? Karl Hi Karl, If it is possible, Ant chmod task can be used, or you can consult the implementation. But Ant manual says for the task: Right now it has effect only under Unix or NonStop Kernel (Tandem). http://ant.apache.org/manual/Tasks/chmod.html Koji -- http://www.rondhuit.com/en/
RE: Derby/JUnit bad interaction - any ideas?
Huh. I wonder how ant is doing it? Using the ant task directly makes it impossible to do this from within JUnit, of course, but maybe the same hack can be done inside the test stuff. Karl -Original Message- From: ext Koji Sekiguchi [mailto:k...@r.email.ne.jp] Sent: Tuesday, June 08, 2010 10:08 AM To: connectors-dev@incubator.apache.org Subject: Re: Derby/JUnit bad interaction - any ideas? (10/06/08 22:35), karl.wri...@nokia.com wrote: I've been trying to get some basic tests working under Junit. Unfortunately, I've run into a Derby problem which prevents these tests from working. What happens is this. Derby, when it creates a database, forces a number of directories within the database to read-only. Unfortunately, unless we stipulate Java 1.6 or up, there is no native Java way to make these directories become non-read-only. So database cleanup always fails to actually remove the old database, and then new database creation subsequently fails. So there are two possibilities. First, we can change things so we never actually try to clean up the Derby DB. Second, we can mandate the java 1.6 is used for LCF. That's all there really is. The first possibility is tricky but doable - I think. The second would probably be unacceptable in many ways. Thoughts? Karl Hi Karl, If it is possible, Ant chmod task can be used, or you can consult the implementation. But Ant manual says for the task: Right now it has effect only under Unix or NonStop Kernel (Tandem). http://ant.apache.org/manual/Tasks/chmod.html Koji -- http://www.rondhuit.com/en/
RE: Derby/JUnit bad interaction - any ideas?
Yeah, I was pretty surprised too. But on windows it is likely that File.makeReadOnly() (which is what Derby must be using) doesn't actually do anything to directories, which would explain the discrepancy. Karl -Original Message- From: ext Mark Miller [mailto:markrmil...@gmail.com] Sent: Tuesday, June 08, 2010 9:45 AM To: connectors-dev@incubator.apache.org Subject: Re: Derby/JUnit bad interaction - any ideas? On 6/8/10 6:35 AM, karl.wri...@nokia.com wrote: I've been trying to get some basic tests working under Junit. Unfortunately, I've run into a Derby problem which prevents these tests from working. What happens is this. Derby, when it creates a database, forces a number of directories within the database to read-only. Unfortunately, unless we stipulate Java 1.6 or up, there is no native Java way to make these directories become non-read-only. So database cleanup always fails to actually remove the old database, and then new database creation subsequently fails. So there are two possibilities. First, we can change things so we never actually try to clean up the Derby DB. Second, we can mandate the java 1.6 is used for LCF. That's all there really is. The first possibility is tricky but doable - I think. The second would probably be unacceptable in many ways. Thoughts? Karl Interesting - when I worked with derby in the past, I never had any trouble deleting a database after shutting it down on windows using Java 5. It worked great with my unit tests. You could always run each test in a new system tmp dir every time... I find it hard to believe you cannot delete the database somehow though - like I said, I never had any problems with it using embedded derby in the past after shutting down the db. -- - Mark http://www.lucidimagination.com
Re: Derby/JUnit bad interaction - any ideas?
(10/06/08 23:14), karl.wri...@nokia.com wrote: Yeah, I was pretty surprised too. But on windows it is likely that File.makeReadOnly() (which is what Derby must be using) doesn't actually do anything to directories, which would explain the discrepancy. Karl If so, luckily Ant hack can solve the problem on Linux. Koji -- http://www.rondhuit.com/en/
RE: Derby/JUnit bad interaction - any ideas?
I just had a look at the sources. Ant's chmod task queries what kind of OS it is, and if it is the right kind, it actually attempts to fire off the chmod utility. ;-) That's pretty hacky. Nice to avoid that if possible. Now, I was able to get my current set of brain-dead tests to work OK (and the ant cleanup too!) by making sure that the database was properly cleaned after every use, and leaving it around for later. It turns out that ant can delete the testing directory even though the directory underneath it has read-only stuff in it, even without the chmod. This seems to be because when it fails any deletion, it simply calls f.deleteOnExit() and lets the JVM do it later - and apparently the JVM *can* do this, because it's implemented to just do an unlink at that time, which bypasses the need to actually delete any read-only subdirectories. Oh my. What a strange mess. Still, things are currently working, so I guess I'll leave them as they are, for now. Karl -Original Message- From: ext Koji Sekiguchi [mailto:k...@r.email.ne.jp] Sent: Tuesday, June 08, 2010 10:30 AM To: connectors-dev@incubator.apache.org Subject: Re: Derby/JUnit bad interaction - any ideas? (10/06/08 23:14), karl.wri...@nokia.com wrote: Yeah, I was pretty surprised too. But on windows it is likely that File.makeReadOnly() (which is what Derby must be using) doesn't actually do anything to directories, which would explain the discrepancy. Karl If so, luckily Ant hack can solve the problem on Linux. Koji -- http://www.rondhuit.com/en/
Re: Derby/JUnit bad interaction - any ideas?
If we need to require Java 1.6, that is probably okay. I am fine with that. Does anybody have a serious objection to requiring Java 1.6 for LCF? -- Jack Krupansky -- From: karl.wri...@nokia.com Sent: Tuesday, June 08, 2010 6:35 AM To: connectors-dev@incubator.apache.org Subject: Derby/JUnit bad interaction - any ideas? I've been trying to get some basic tests working under Junit. Unfortunately, I've run into a Derby problem which prevents these tests from working. What happens is this. Derby, when it creates a database, forces a number of directories within the database to read-only. Unfortunately, unless we stipulate Java 1.6 or up, there is no native Java way to make these directories become non-read-only. So database cleanup always fails to actually remove the old database, and then new database creation subsequently fails. So there are two possibilities. First, we can change things so we never actually try to clean up the Derby DB. Second, we can mandate the java 1.6 is used for LCF. That's all there really is. The first possibility is tricky but doable - I think. The second would probably be unacceptable in many ways. Thoughts? Karl
