RE: Derby/JUnit bad interaction - any ideas?
This actually did work, oddly enough. I wonder how Derby is undoing the read-only attribute on those directories? But in any case, I'm revamping the core setup/shutdown code again so that there's a decent hook in place to do the derby shutdown. Karl -Original Message- From: ext Mark Miller [mailto:markrmil...@gmail.com] Sent: Wednesday, June 09, 2010 4:26 PM 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 > > > > So I've been thinking about this - I still have trouble believing this is a real problem. I had a large suite of tests that used embedded derby in a system I worked on a few years back - and I never had any trouble removing the db dir after shutting down derby. Looking at the code, have you actually tried shutting down derby? Currently you have: // Cause database to shut down new Database(context,_url+databaseName+";shutdown=true",_driver,databaseName,"",""); // DO NOT delete user or shutdown database, since this is in fact impossible under java 1.5 (since Derby makes its directories read-only, and // there's no way to undo that... // rm -rf //File f = new File(databaseName); //recursiveDelete(f); But that is not going to do the shutdown? On a quick look, doing new Database(context, url ... does not actually contact the db - so its not going to cause it to shutdown? Is this just cruft code and you have actually tried shutting down as well? Something makes me think the delete is going to work if you actually attempt to connect with '...;shutdown=true' jdbc URL. -- - Mark http://www.lucidimagination.com
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 So I've been thinking about this - I still have trouble believing this is a real problem. I had a large suite of tests that used embedded derby in a system I worked on a few years back - and I never had any trouble removing the db dir after shutting down derby. Looking at the code, have you actually tried shutting down derby? Currently you have: // Cause database to shut down new Database(context,_url+databaseName+";shutdown=true",_driver,databaseName,"",""); // DO NOT delete user or shutdown database, since this is in fact impossible under java 1.5 (since Derby makes its directories read-only, and // there's no way to undo that... // rm -rf //File f = new File(databaseName); //recursiveDelete(f); But that is not going to do the shutdown? On a quick look, doing new Database(context, url ... does not actually contact the db - so its not going to cause it to shutdown? Is this just cruft code and you have actually tried shutting down as well? Something makes me think the delete is going to work if you actually attempt to connect with '...;shutdown=true' jdbc URL. -- - Mark http://www.lucidimagination.com
RE: Derby/JUnit bad interaction - any ideas?
I take this partially back. The gcj jvm is the one that doesn't work with ant. At any rate, going to a different JVM is something I can only influence but can't control, so that's probably not going to happen for a while. Karl From: Wright Karl (Nokia-S/Cambridge) Sent: Wednesday, June 09, 2010 5:24 AM To: connectors-dev@incubator.apache.org Subject: RE: Derby/JUnit bad interaction - any ideas? Open jdk does not seem to work properly with most java applications at this time, although it has continued to improve. Its switch incompatibilities stop it from working with ant at this time, so one cannot even build LCF with it. Karl From: ext Olivier Bourgeat [olivier.bourg...@polyspot.com] Sent: Wednesday, June 09, 2010 4:03 AM To: connectors-dev@incubator.apache.org Subject: RE: Derby/JUnit bad interaction - any ideas? Debian Lenny have openjdk-6: http://packages.debian.org/fr/source/lenny/openjdk-6 Olivier Le mardi 08 juin 2010 à 22:37 +0200, karl.wri...@nokia.com a écrit : > MetaCarta is running Debian Lenny, which does not have a 1.6 version of Java > available at this time. > > Karl > > > -Original Message- > From: ext Jack Krupansky [mailto:jack.krupan...@lucidimagination.com] > Sent: Tuesday, June 08, 2010 4:36 PM > To: connectors-dev@incubator.apache.org > Subject: 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: > Sent: Tuesday, June 08, 2010 6:35 AM > To: > 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 > > > > > > > >
RE: Derby/JUnit bad interaction - any ideas?
Open jdk does not seem to work properly with most java applications at this time, although it has continued to improve. Its switch incompatibilities stop it from working with ant at this time, so one cannot even build LCF with it. Karl From: ext Olivier Bourgeat [olivier.bourg...@polyspot.com] Sent: Wednesday, June 09, 2010 4:03 AM To: connectors-dev@incubator.apache.org Subject: RE: Derby/JUnit bad interaction - any ideas? Debian Lenny have openjdk-6: http://packages.debian.org/fr/source/lenny/openjdk-6 Olivier Le mardi 08 juin 2010 à 22:37 +0200, karl.wri...@nokia.com a écrit : > MetaCarta is running Debian Lenny, which does not have a 1.6 version of Java > available at this time. > > Karl > > > -Original Message- > From: ext Jack Krupansky [mailto:jack.krupan...@lucidimagination.com] > Sent: Tuesday, June 08, 2010 4:36 PM > To: connectors-dev@incubator.apache.org > Subject: 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: > Sent: Tuesday, June 08, 2010 6:35 AM > To: > 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 > > > > > > > >
RE: Derby/JUnit bad interaction - any ideas?
Debian Lenny have openjdk-6: http://packages.debian.org/fr/source/lenny/openjdk-6 Olivier Le mardi 08 juin 2010 à 22:37 +0200, karl.wri...@nokia.com a écrit : > MetaCarta is running Debian Lenny, which does not have a 1.6 version of Java > available at this time. > > Karl > > > -Original Message- > From: ext Jack Krupansky [mailto:jack.krupan...@lucidimagination.com] > Sent: Tuesday, June 08, 2010 4:36 PM > To: connectors-dev@incubator.apache.org > Subject: 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: > Sent: Tuesday, June 08, 2010 6:35 AM > To: > 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 > > > > > > > >
RE: Derby/JUnit bad interaction - any ideas?
MetaCarta is running Debian Lenny, which does not have a 1.6 version of Java available at this time. Karl -Original Message- From: ext Jack Krupansky [mailto:jack.krupan...@lucidimagination.com] Sent: Tuesday, June 08, 2010 4:36 PM To: connectors-dev@incubator.apache.org Subject: 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: Sent: Tuesday, June 08, 2010 6:35 AM To: 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 > > > >
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: Sent: Tuesday, June 08, 2010 6:35 AM To: 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
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?
(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?
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?
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?
(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?
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
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
