Derby
  1. Derby
  2. DERBY-4907

EmbeddedXADataSource with ;create=true attribute set in setDatabaseName fails with java.sql.SQLException: Database not available

    Details

    • Urgency:
      Low
    • Issue & fix info:
      Newcomer, Repro attached, Workaround attached

      Description

      Setting the ;create=true attribute in setDatabaseName with EmbededXADataSource and EmbeddedXADataSource40 fails with
      $ java TestDerbyCreate
      Exception in thread "main" java.sql.SQLException: Database not available
      at org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter(Embe
      dedXADataSource.java:175)
      at org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(EmbeddedX
      DataSource.java:101)
      at TestDerbyCreate.main(TestDerbyCreate.java:18)

      using the create attributie in databaseName works fine with EmbeddedDataSource.

      Using setCreateDatabase("create") with EmbeddedXADataSource is a good work around and I think generally preferable.

      import java.sql.*;
      import javax.sql.*;

      public class TestDerbyCreate
      {
      public static void main(String[] args) throws Throwable
      {
      org.apache.derby.jdbc.EmbeddedXADataSource ds =
      new
      org.apache.derby.jdbc.EmbeddedXADataSource();

      ds.setDatabaseName("TestDB;create=true");
      ds.setUser("dbuser1");
      ds.setPassword("dbpwd1");

      PooledConnection pooledConn = ds.getXAConnection();
      Connection conn = pooledConn.getConnection();

      System.out.println("Database product: " +
      conn.getMetaData().getDatabaseProductName());
      System.out.println("Database version: " +
      conn.getMetaData().getDatabaseProductVersion());
      System.out.println("Driver name: " +
      conn.getMetaData().getDriverName());
      System.out.println("Driver version: " +
      conn.getMetaData().getDriverVersion());
      System.out.println("JDBC driver major ve

      1. derby4907_final.diff
        5 kB
        Siddharth Srivastava
      2. derby4907_with_contains_fix.diff
        6 kB
        Dave Brosius
      3. derby4907.diff
        6 kB
        Siddharth Srivastava
      4. derby4907.diff
        5 kB
        Siddharth Srivastava
      5. derby4907.diff
        7 kB
        Siddharth Srivastava
      6. derby4907.diff
        7 kB
        Siddharth Srivastava
      7. derby4907.txt
        2 kB
        Siddharth Srivastava

        Issue Links

          Activity

          Hide
          Siddharth Srivastava added a comment -

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

          Show
          Siddharth Srivastava added a comment - Initially the problem seem to be with the findService. Though database is being created in the default location as per the repro attached above.
          Hide
          Siddharth Srivastava added a comment -

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

          Show
          Siddharth Srivastava added a comment - What coding and naming conventions need to be followed for Derby ? Is there any documentation related to the same.
          Hide
          Siddharth Srivastava added a comment -

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

          Show
          Siddharth Srivastava added a comment - Discussed with Kathey on IRC. Got the appropriate resources. Thanks Kathey
          Hide
          Siddharth Srivastava added a comment -

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

          { String dbShort = shortDatabaseName(); //other code if (Monitor.getMonitor() != null) database = (Database) Monitor.findService(Property.DATABASE_MODULE, dbShort); }

          String shortDatabaseName is defined as follows:

          { String delim = "[;]"; String[] dbShort = databaseName.split(delim); return dbShort[0]; }

          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)

          Show
          Siddharth Srivastava added a comment - adding this to EmbeddedXADataSource.java if (dbName != null) { String dbShort = shortDatabaseName(); //other code if (Monitor.getMonitor() != null) database = (Database) Monitor.findService(Property.DATABASE_MODULE, dbShort); } String shortDatabaseName is defined as follows: { String delim = "[;]"; String[] dbShort = databaseName.split(delim); return dbShort[0]; } 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)
          Hide
          Kathey Marsden added a comment -

          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.

          Show
          Kathey Marsden added a comment - 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.
          Hide
          Siddharth Srivastava added a comment -

          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

          Show
          Siddharth Srivastava added a comment - 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
          Hide
          Siddharth Srivastava added a comment -

          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.

          Show
          Siddharth Srivastava added a comment - 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.
          Hide
          Siddharth Srivastava added a comment -

          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.

          Show
          Siddharth Srivastava added a comment - 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.
          Hide
          Kathey Marsden added a comment -

          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.

          Show
          Kathey Marsden added a comment - 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.
          Hide
          Kathey Marsden added a comment -

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

          Show
          Kathey Marsden added a comment - oops. shortDatabaseName() is already in ReferenceableDataSource! I looked at the diff too quickly. Looks good then.
          Hide
          Siddharth Srivastava added a comment -

          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.

          Show
          Siddharth Srivastava added a comment - 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.
          Hide
          Kathey Marsden added a comment -

          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.

          Show
          Kathey Marsden added a comment - 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.
          Hide
          Siddharth Srivastava added a comment -

          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.

          Show
          Siddharth Srivastava added a comment - 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.
          Hide
          Siddharth Srivastava added a comment -

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

          Show
          Siddharth Srivastava added a comment - thanks Kathey for the suggestion. I am much clear about the loop I was getting in
          Hide
          Kathey Marsden added a comment -

          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

          Show
          Kathey Marsden added a comment - 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
          Hide
          Siddharth Srivastava added a comment -

          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

          Show
          Siddharth Srivastava added a comment - 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
          Hide
          Siddharth Srivastava added a comment -

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

          Show
          Siddharth Srivastava added a comment - Sorry for the noise, I forgot to grant the license to previous attachment for inclusion in ASF works. Thanks
          Hide
          Tiago R. Espinha added a comment -

          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

          Show
          Tiago R. Espinha added a comment - 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
          Hide
          Kathey Marsden added a comment -

          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.

          Show
          Kathey Marsden added a comment - 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.
          Hide
          Tiago R. Espinha added a comment -

          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".

          Show
          Tiago R. Espinha added a comment - 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".
          Hide
          Kathey Marsden added a comment -

          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.

          Show
          Kathey Marsden added a comment - 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.
          Hide
          Kathey Marsden added a comment -

          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.

          Show
          Kathey Marsden added a comment - 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.
          Hide
          Siddharth Srivastava added a comment -

          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.

          Show
          Siddharth Srivastava added a comment - 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.
          Hide
          Siddharth Srivastava added a comment -

          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

          Show
          Siddharth Srivastava added a comment - 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
          Hide
          Tiago R. Espinha added a comment -

          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/

          Show
          Tiago R. Espinha added a comment - 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/
          Hide
          Siddharth Srivastava added a comment -

          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.

          Show
          Siddharth Srivastava added a comment - 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.
          Hide
          Kristian Waagan added a comment -

          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).

          Show
          Kristian Waagan added a comment - 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).
          Hide
          Tiago R. Espinha added a comment -

          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.

          Show
          Tiago R. Espinha added a comment - 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.
          Hide
          Rick Hillegas added a comment -

          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.

          Show
          Rick Hillegas added a comment - 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.
          Hide
          Dave Brosius added a comment - - edited

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

          Show
          Dave Brosius added a comment - - edited added patch (derby4907_with_contains_fix.diff) that switched the contains to indexOf(..) >= 0 for 1.4 compatibiilty
          Hide
          Tiago R. Espinha added a comment -

          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.

          Show
          Tiago R. Espinha added a comment - 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.
          Hide
          Tiago R. Espinha added a comment -

          Committed with revision 1078461.

          @ Siddharth,

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

          Show
          Tiago R. Espinha added a comment - Committed with revision 1078461. @ Siddharth, Please keep an eye out for regressions and close the issue if everything goes fine.
          Hide
          Siddharth Srivastava added a comment -

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

          Show
          Siddharth Srivastava added a comment - Thanks Tiago for committing and providing useful suggestions. Thanks Dave, Rick for your inputs.
          Hide
          Kathey Marsden added a comment -

          reopen for backport to 10.5

          Show
          Kathey Marsden added a comment - reopen for backport to 10.5
          Hide
          Kathey Marsden added a comment -

          backported to 10.5. Thanks Siddharth for the fix.

          Show
          Kathey Marsden added a comment - backported to 10.5. Thanks Siddharth for the fix.

            People

            • Assignee:
              Siddharth Srivastava
              Reporter:
              Kathey Marsden
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development