Initially the problem seem to be with the findService. Though database is being created in the default location as per the repro attached above.

What coding and naming conventions need to be followed for Derby ? Is there any documentation related to the same.

Discussed with Kathey on IRC. Got the appropriate resources. Thanks Kathey

adding this to EmbeddedXADataSource.java
if (dbName != null)

String shortDatabaseName is defined as follows:

Now java TestDerbyCreate.java gives this error:

Default implementation list not found
XBM02.D : [0] org.apache.derby.iapi.services.stream.InfoStreams
ERROR XBM02: XBM02.D : [0] org.apache.derby.iapi.services.stream.InfoStreams
at org.apache.derby.iapi.error.StandardException.newException(StandardEx
ception.java:286)
at org.apache.derby.iapi.services.monitor.Monitor.missingImplementation(
Monitor.java:672)
at org.apache.derby.impl.services.monitor.TopService.bootModule(TopServi
ce.java:325)
at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMo
nitor.java:531)
at org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Moni
tor.java:366)
at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseM
onitor.java:344)
at org.apache.derby.impl.services.monitor.FileMonitor.<init>(FileMonitor
.java:60)
at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.j
ava:289)
at org.apache.derby.iapi.jdbc.JDBCBoot.boot(JDBCBoot.java:69)
at org.apache.derby.jdbc.EmbeddedDriver.boot(EmbeddedDriver.java:199)
at org.apache.derby.jdbc.EmbeddedDriver.<clinit>(EmbeddedDriver.java:96)

at org.apache.derby.jdbc.EmbeddedDataSource.findDriver(EmbeddedDataSourc
e.java:501)
at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(EmbeddedDataSo
urce.java:480)
at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(EmbeddedDataSo
urce.java:424)
at org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter(Embed
dedXADataSource.java:166)
at org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(EmbeddedXA
DataSource.java:101)
at TestDerbyCreate.main(TestDerbyCreate.java:16)

Exception in thread "main" java.sql.SQLException: No suitable driver
at java.sql.DriverManager.getDriver(Unknown Source)
at org.apache.derby.jdbc.EmbeddedDataSource.findDriver(EmbeddedDataSourc
e.java:506)
at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(EmbeddedDataSo
urce.java:480)
at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(EmbeddedDataSo
urce.java:424)
at org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter(Embed
dedXADataSource.java:166)
at org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(EmbeddedXA
DataSource.java:101)
at TestDerbyCreate.main(TestDerbyCreate.java:16)

I think this might be a problem with your build. I would ant clobber and remove your old jars and then rebuild checking carefully that there are no build errors. If I am not mistaken it is not getting as far as the original error.

build errors weren't there earlier too. jars were required to be manually removed. Shouldn't they be overwritten ?

Just tested again with all modifications made i.e. passing database name to the findService(). Now it seems to work

Output is:
Database product: Apache Derby
Database version: 10.8.0.0 alpha - (???)
Driver name: Apache Derby Embedded JDBC Driver
Driver version: 10.8.0.0 alpha - (???)
JDBC driver major ve

The code changes done seem to resolve this issue. I have created a patch using Eclipse (Team->create Patch). But when I upload it on jira using:
MoreActions->Attach File, I get Unknown error occurred uploading file.

I have attached a patch for the changes I have made. The code changes work fine for me.
Now I have started writing regression test cases for it.

Thank you Siddharth for working on this issue. My only substantive comment is I think it would make sense to move shortDatabaseName all the way up to ReferenceableDatasource in case it is needed for other DataSources since it is not related to XA. There also seemed to be a white space diff introduced in update() that would be good to get rid of in the final patch. I am looking forward to seeing your test. Keep up the good work.

oops. shortDatabaseName() is already in ReferenceableDataSource! I looked at the diff too quickly. Looks good then.

thanks Kathey for your review. I will remove the redundant space in the final diff.

While writing junit test, I was a bit confused over getting datasources for test in J2EEDataSourceTest.java. As we need to test the function in EmbeddedXADataSource, so is there a way to convert between the two or a specific methods needs to be written for EmbeddedXADataSource as for XADataSource in J2EEDataSource.java. (which I think would need certain addition to the JDBCClient.java too )
I think I am missing a link in here.

J2EEDatasource.getXADatasource() is smart and will get the right XADatasource, one of 4, EmbeddedXADatasource, EmbeddedXADatasource40, ClientXADatasource or ClientXADatasource40. Try running the test printing the claasname of the datasource you get in the fixture. You will see with JDK 1.6 you cover the 40 ones and with JDK 1.5 to see the others.

The diff consists of the bug fix and the regression test.

As far as the empty line is concerned, my observation says that its a whitespace. I set my editor to remove it but somehow the change is not getting detected. Would try to fix that the redundant whitespaces till the review goes on.

thanks Kathey for the suggestion. I am much clear about the loop I was getting in

Thanks Siddharth. I think if databaseName is an empty string "", which is what is used for engine shutdown, shortDatabaseName will return null instead of "";

Maybe instead do the split only if the databaseName is not null and if it contains a semicolon. Otherwise return databaseName. That way we only have the overhead of the split call when it is really needed and don't have to worry so much about these edge cases.

In the test I think it would also be good to test with the other datasource types, JDBCDataSource.getDataSource() and J2EEDataSource.getConnectionPoolDataSource() too. These were not broken before but good to have coverage.

I think I would not include spelling corrections that are far removed from the code change, especially in files that have no code changes. This type of thing is best done separately.

Thanks

Kathey

Thanks Kathey for your review.

I would keep in mind to not to change the comments. It really looks odd.

I have added tests for JDBCDataSource, Pool DataSource and XADataSource.

As well as modified the shortDatabseName for avoiding unnecessary split.

Thanks

Sorry for the noise, I forgot to grant the license to previous attachment for inclusion in ASF works.
Thanks

Hi Siddharth,

I've skimmed through the patch and it looks good, but I have one remark. When you submit a patch, try to avoid white-space changes like the second change in your latest patch. As you can see, the only difference is that you added a tab character in front of the bracket, which makes svn pick it up as a change and makes it harder to review the patch.

There's a few more cases like:

• xa.close();
  + xa.close();
  (again, the same situation with the tab)

It's a cosmetic thing but especially with large patches, it does matter for whoever's reviewing it.

I will give the patch a better look later today, once I get home.

Thanks

For the white space issue, I have found in Eclipse that the setting Windows ->Preferences -> General ->Editors -> Text Editors -> Show whitespace characters is very helpful to differentiate tabs and spaces. Although they don't show with <right click> compare you can move the cursor in the white space to see the difference. Tabs will jump several spaces.

I think the patch is fine based on a cursory review. I will let Tiago do the commit since he wants to take a look at it too.

I think you asked a couple important questions on IRC that I wanted to answer here. Maybe you answered them yourself as I don't see any such issues with the patch.

Q1) Shouldn't shortDatabaseName do some checking on the validity of the database name format?
I am not sure what checking would be required, but If there is any checking needed on the databaseName that should occur in setDatabaseName at the time that the user sets it, rather than in shortDatabaseName where it is just being parsed in the getConneciton() call.

Q2) Shouldn't errors print or be logged somewhere?
Because Derby is typically embedded in an application, the way we generally communicate problems to the application is by throwing an Exception. That way the application can either catch the exception and handle it or throw it back to the user if appropriate. These can optionally be logged to the derby.log if the user wants by setting the derby.stream.error.logSeverity property http://db.apache.org/derby/manuals/tuning/perf90.html
If your work ever requires adding a new message for an exception, give the list a ping as there are some steps needed to make sure the message is localized, etc.

Ok, I have a couple more comments. I agree with Kathey. The short database name is something that we can manage whenever a database name is set. We could have an attribute shortDatabaseName that we define whenever the actual database name is set (setDatabaseName). Then the getShortName() method would simply return this field, without having to do any kind of checks (Kathey, you mention checking but I can't seem to think of anything that would be required...).

I've also noticed that you have: a) spelling changes, b) production code changes and c) test additions in one single patch. I'm not sure if everyone will agree with me on this, but I've always done code changes and test changes in separate patches. Sure, maybe for a small patch like this it doesn't matter much, but when we start dealing with larger patches, I think it's good practice to keep the two separated.

I might also be nit picking but I would prefer (for standard's sake) that getter methods (like shortDatabaseName() ) would actually start with "get".

It would be a good performance optimization to set a shortDatabaseName field on set rather than parsing databaseName on every connection. I think the current implementation is ok too as I don't think it creates that big a hit.

I have always combined code and test in the patch, but it actually would be nice to have them separate so the reviewer could run the test first and see that it fails and then with the code change to see that it passes. Maybe I'll start doing that #

On shortName() vs getShortName() I think the name is ok. I am concerned that often reflection is used to get the bean properties on DataSources and don't want this one to show up but perhaps if it is not public that is not an issue. I am just not sure. Also as it is currently implemented it is not just a straight getter and does some manipulation so the name is ok in that regard too.

I see in the javadoc for getDeclaredMethods() http://download.oracle.com/javase/6/docs/api/java/lang/Class.html#getDeclaredMethods() it does return non-public methods but does not return inherited methods. Since getShortDatabaseName() would be in ReferenceableDataSource I think it would be safe to call it that and not worry about it showing up as a phantom bean property in reflection.

Thanks Kathey, Tiago for your review.

I have removed erroneous spaces and edits. Also I have removed shortDatabaseName() and moved that to setDatabaseName.

three tests(for XA DataSource, JDBC DataSource, PoolDataSource) are also added.

Testing: the individual test runs successfully.

When I run the suites.All, I get the following 2 errors

run "suites.All" I get this error : ( I emptied the directory from which I was running tests before starting running suites.All)

[Error/failure logged at Sat Feb 19 15:40:32 IST 2011]
java.sql.SQLException: An IOException occurred while writing data to the file.
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:98)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142)
at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:278)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:348)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2290)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1334)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1686)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(EmbedPreparedStatement.java:1341)
at org.apache.derbyTesting.functionTests.tests.tools.ImportExportBaseTest.doExportQueryLobsToExtFile(ImportExportBaseTest.java:197)
at org.apache.derbyTesting.functionTests.tests.tools.ImportExportLobTest.testImportDataExportQueryLobsInExtFile(ImportExportLobTest.java:332)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at junit.textui.TestRunner.doRun(TestRunner.java:121)
at junit.textui.TestRunner.start(TestRunner.java:185)
at junit.textui.TestRunner.main(TestRunner.java:143)
Caused by: java.sql.SQLException: An IOException occurred while writing data to the file.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:122)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
... 42 more
Caused by: java.sql.SQLException: Java exception: 'extinout\books.del (Access is denied): java.io.FileNotFoundException'.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:122)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142)
at org.apache.derby.impl.jdbc.Util.javaException(Util.java:299)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:408)
... 40 more
Caused by: java.io.FileNotFoundException: extinout\books.del (Access is denied)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(Unknown Source)
at java.io.FileOutputStream.<init>(Unknown Source)
at org.apache.derby.impl.load.ExportWriteData.openFiles(ExportWriteData.java:108)
at org.apache.derby.impl.load.ExportWriteData.run(ExportWriteData.java:93)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.derby.impl.load.ExportWriteData.init(ExportWriteData.java:85)
at org.apache.derby.impl.load.ExportWriteData.<init>(ExportWriteData.java:78)
at org.apache.derby.impl.load.Export.getExportWriteData(Export.java:296)
at org.apache.derby.impl.load.ExportAbstract.doAllTheWork(ExportAbstract.java:187)
at org.apache.derby.impl.load.Export.doExport(Export.java:65)
at org.apache.derby.impl.load.Export.exportQuery(Export.java:285)
at org.apache.derby.catalog.SystemProcedures.SYSCS_EXPORT_QUERY_LOBS_TO_EXTFILE(SystemProcedures.java:1430)
at org.apache.derby.exe.ac685dd88bx012ex3d61x7f08x00004762b9942.g0(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(ReflectMethod.java:46)
at org.apache.derby.impl.sql.execute.CallStatementResultSet.open(CallStatementResultSet.java:75)
at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:436)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:317)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242)
... 35 more

2) [Error/failure logged at Sat Feb 19 17:04:10 IST 2011]
java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ041, SQLERRMC: Failed to create database 'F:\eclipsework\testGarbage\db_master\wombat', see the next exception for details.::SQLSTATE: XBM0JDirectory F:\eclipsework\testGarbage\db_master\F:\eclipsework\testGarbage\db_master\wombat already exists.
at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:99)
at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:358)
at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:166)
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.bootMasterDatabase(ReplicationRun.java:868)
at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.makeReadyForReplication(ReplicationRun.java:2746)
at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_1Indexing.testReplication_Local_1_Indexing(ReplicationRun_Local_1Indexing.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112)
at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.runBare(ReplicationRun.java:207)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at junit.textui.TestRunner.doRun(TestRunner.java:121)
at junit.textui.TestRunner.start(TestRunner.java:185)
at junit.textui.TestRunner.main(TestRunner.java:143)
Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ041, SQLERRMC: Failed to create database 'F:\eclipsework\testGarbage\db_master\wombat', see the next exception for details.::SQLSTATE: XBM0JDirectory F:\eclipsework\testGarbage\db_master\F:\eclipsework\testGarbage\db_master\wombat already exists.
at org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2121)
at org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(NetConnectionReply.java:541)
at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java:434)
at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java:297)
at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java:121)
at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java:846)
at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java:769)
at org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(NetConnection.java:601)
at org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:408)
at org.apache.derby.client.net.NetConnection.<init>(NetConnection.java:218)
at org.apache.derby.client.net.NetConnection40.<init>(NetConnection40.java:79)
at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(ClientJDBCObjectFactoryImpl40.java:269)
at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:157)
... 34 more

FAILURES!!!
Tests run: 13327, Failures: 0, Errors: 2

This looks most definitely like a permissions issue: "Caused by: java.sql.SQLException: Java exception: 'extinout\books.del (Access is denied): java.io.FileNotFoundException'. "

Maybe you can try to disable UAC [1] and give it another try? Then if it works, we'll know what's causing it and we can try a more gentle approach (maybe just changing the permissions of the folder...).

I'm not sure, but maybe running the command line in elevated mode (right click on it, and "Run as Administrator) would also fix it, but I'd still give it a try just with UAC disabled beforehand.

[1] - http://www.mydigitallife.info/2008/12/30/how-to-disable-and-turn-off-uac-in-windows-7/

In continuation to previous comment:

I have tried closing the connection in my tests.

With this 3 tests failed while running suites.All, namely,
1) AutomaticIndexStatisticsTests
2) ReplicationRun_Local_1Indexing
3) RolesTest

I tried running these tests individually:
AutomaticIndexStatisticsTests failed with the following error:

There was 1 failure:
1) testShutdownWhileScanningThenDelete(org.apache.derbyTesting.functionTests.tes
ts.store.AutomaticIndexStatisticsTest)junit.framework.AssertionFailedError: Fail
ed to delete 3 files (root=F:\eclipsework\testGarbage\system\singleUse\copyShutd
own: F:\eclipsework\testGarbage\system\singleUse\copyShutdown\seg0\c481.dat (isD
ir=false, canRead=true, canWrite=true, size=22351872), F:\eclipsework\testGarbag
e\system\singleUse\copyShutdown\seg0 (isDir=true, canRead=true, canWrite=true, s
ize=12288), F:\eclipsework\testGarbage\system\singleUse\copyShutdown (isDir=true
, canRead=true, canWrite=true, size=4096)
at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertDirectoryDeleted
(BaseJDBCTestCase.java:1496)
at org.apache.derbyTesting.functionTests.tests.store.AutomaticIndexStati
sticsTest.testShutdownWhileScanningThenDelete(AutomaticIndexStatisticsTest.java:
188)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
112)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57
)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)

FAILURES!!!
Tests run: 7, Failures: 1, Errors: 0

Other two tests passed.

The failure in testShutdownWhileScanningThenDelete is most likely an intermittent failure seen on Windows only.
You can try to run it individually again, or apply patch 1a attached to DERBY-4915.

If the test is failing consistently on your machine, it would be interesting to know if the patch I mentioned helps, and further if adding a sleep after the database shutdown makes the problem go away without the patch.

Feel free to add a comment to DERBY-4915 if you choose to test the patch, or add a sleep (i.e. either directly in the test or by modifying the shutdown method(s) in the test framework).

I ran derbyall without any failures, and the failures on suites.All also seem to be unrelated intermittent issues.

Committed Siddharth's patch with revision 1077955.

@ Siddharth, I will now resolve the issue. Please keep an eye on the regression runs for tomorrow and make sure there are no failures (also make sure that these changes are already picked up by that regression run by checking the revision number of the run). If there are no failures, then please go ahead and close the issue on JIRA.

The previous submission broke the Derby build. Because we are close to generating a release, I have backed out that fix at subversion revision 1077998.

added patch (derby4907_with_contains_fix.diff) that switched the contains to indexOf(..) >= 0 for 1.4 compatibiilty

Apologies for breaking the build .

I hadn't set up the 1.4 JDK on my server and I also didn't pick this up on visual inspection. Thank you Dave for the fixed patch. Since this is a really small change that maintains the same functionality, I'm gonna go ahead and commit Dave's patch so that it makes it to the 10.8.1 release candidate.

@ Siddharth,

Due to backwards compatibility issues, we make sure that Derby's code complies with version 1.4 of the JDK. This means that certain features that were introduced in Java 1.5 and 1.6 can't be used, as they would break this compatibility with older JDKs. The method .contains() is one of these features.

What you can do to ensure that your code is 1.4-compliant is download a 1.4 JDK and point to it on the ant.properties file. For more information on how to do this, you can check the BUILDING.html file in the root of Derby's SVN trunk.

In very general terms though, you need to create a file called ant.properties, put it on your home directory, and make its contents look something like this: j14lib=/usr/local/bin/jdks/j2sdk1.4.2_19/jre/lib/

Then when you compile the code using 'ant all', it will automatically try to compile it against the 1.4 JDK.

Committed with revision 1078461.

@ Siddharth,

Please keep an eye out for regressions and close the issue if everything goes fine.

Thanks Tiago for committing and providing useful suggestions.
Thanks Dave, Rick for your inputs.

reopen for backport to 10.5

backported to 10.5. Thanks Siddharth for the fix.