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: 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
[jira] Created: (CONNECTORS-43) Useless call to String.trim() in org.apache.lcf.ui.util.MultilineParser
Useless call to String.trim() in org.apache.lcf.ui.util.MultilineParser
---
Key: CONNECTORS-43
URL: https://issues.apache.org/jira/browse/CONNECTORS-43
Project: Lucene Connector Framework
Issue Type: Bug
Reporter: Mark Miller
Priority: Trivial
{code}
nextString.trim();
{code}
should likely be:
{code}
nextString = nextString.trim();
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
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 databasename //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
[jira] Assigned: (CONNECTORS-43) Useless call to String.trim() in org.apache.lcf.ui.util.MultilineParser
[
https://issues.apache.org/jira/browse/CONNECTORS-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright reassigned CONNECTORS-43:
-
Assignee: Karl Wright
Useless call to String.trim() in org.apache.lcf.ui.util.MultilineParser
---
Key: CONNECTORS-43
URL: https://issues.apache.org/jira/browse/CONNECTORS-43
Project: Lucene Connector Framework
Issue Type: Bug
Reporter: Mark Miller
Assignee: Karl Wright
Priority: Trivial
{code}
nextString.trim();
{code}
should likely be:
{code}
nextString = nextString.trim();
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
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 databasename //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
