Derby
  1. Derby
  2. DERBY-5955

Prepare Derby to run with Compact Profiles (JEP 161)

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.10.1.1
    • Component/s: JDBC, Services, SQL
    • Labels:
      None

      Description

      While waiting for a Java module system (aka project Jigsaw), it has been decided to define a few subsets of the Java SE Platform Specification, cf JEP 161 ( http://openjdk.java.net/jeps/161).

      A quote from the JEP: "More broadly, this feature is intended to enable the migration of applications currently built on top of the Java ME Connected Device Configuration (CDC) to appropriate Profiles of the Java SE Platform, part of the long-term effort to converge CDC with Java SE."

      It would be good if we make Derby to run on such limited profiles. The current proposal places JDBC in Compact Profile 2 (cf. link above), while other libraries used by Derby, e.g. javax.naming (JNDI) are in Profile 3 (larger).

      It would be good if Derby could run on the smallest posible platform, i.e. Profile 2, but that will probably involve some changes to make Derby gracefully limit functionality when some libraries are missing.

      1. derby-5955-javadoc-followup-2.diff
        4 kB
        Dag H. Wanvik
      2. derby-5955-javadoc-followup.diff
        11 kB
        Dag H. Wanvik
      3. derby-5955-javadoc.status
        2 kB
        Dag H. Wanvik
      4. derby-5955-javadoc.diff
        25 kB
        Dag H. Wanvik
      5. derby-5955-rename.diff
        80 kB
        Dag H. Wanvik
      6. derby-5955-make-tests-run-03.diff
        88 kB
        Dag H. Wanvik
      7. derby-5955-make-tests-run-02.stat
        5 kB
        Dag H. Wanvik
      8. derby-5955-make-tests-run-02.diff
        103 kB
        Dag H. Wanvik
      9. derby-5955-ser-b.zip
        16 kB
        Dag H. Wanvik
      10. derby-5955-make-tests-run-01.stat
        5 kB
        Dag H. Wanvik
      11. derby-5955-make-tests-run-01.diff
        106 kB
        Dag H. Wanvik
      12. derby-5955-add-cp2-to-jars.diff
        3 kB
        Dag H. Wanvik
      13. derby-5955-new-non-jndi-ds-02.stat
        0.9 kB
        Dag H. Wanvik
      14. derby-5955-new-non-jndi-ds-02.diff
        30 kB
        Dag H. Wanvik
      15. derby-5955-new-non-jndi-ds-01.stat
        0.9 kB
        Dag H. Wanvik
      16. derby-5955-new-non-jndi-ds-01.diff
        30 kB
        Dag H. Wanvik
      17. derby-5955-client-restructure-02-delta.diff
        0.6 kB
        Dag H. Wanvik
      18. derby-5955-client-restructure-02.stat
        2 kB
        Dag H. Wanvik
      19. derby-5955-client-restructure-02.diff
        184 kB
        Dag H. Wanvik
      20. derby-5955-client-restructure-01.stat
        2 kB
        Dag H. Wanvik
      21. derby-5955-client-restructure-01.diff
        82 kB
        Dag H. Wanvik
      22. derby-5955-embed-restructure-followup.stat
        0.2 kB
        Dag H. Wanvik
      23. derby-5955-embed-restructure-followup.diff
        3 kB
        Dag H. Wanvik
      24. derby-5955-embed-restructure-04.stat
        1 kB
        Dag H. Wanvik
      25. derby-5955-embed-restructure-04.diff
        81 kB
        Dag H. Wanvik
      26. derby-5955-embed-restructure-03.stat
        1 kB
        Dag H. Wanvik
      27. derby-5955-embed-restructure-03.diff
        85 kB
        Dag H. Wanvik
      28. derby-5955-embed-restructure-02.stat
        1 kB
        Dag H. Wanvik
      29. derby-5955-embed-restructure-02.diff
        84 kB
        Dag H. Wanvik
      30. derby-5955-embed-restructure-01.diff
        84 kB
        Dag H. Wanvik
      31. derby-5955-embed-restructure-01.stat
        1 kB
        Dag H. Wanvik
      32. apidiff.zip
        262 kB
        Dag H. Wanvik
      33. publishedapi.zip
        493 kB
        Dag H. Wanvik
      34. derby-5955-proof-of-concept-2.stat
        9 kB
        Dag H. Wanvik
      35. derby-5955-proof-of-concept-2.diff
        305 kB
        Dag H. Wanvik
      36. publishedapi.zip
        558 kB
        Dag H. Wanvik
      37. old-embedded-graph.png
        71 kB
        Dag H. Wanvik
      38. old-client-graph.png
        72 kB
        Dag H. Wanvik
      39. derby-5955-ser.zip
        30 kB
        Dag H. Wanvik
      40. client-graph.png
        141 kB
        Dag H. Wanvik
      41. embedded-graph.png
        180 kB
        Dag H. Wanvik
      42. derby-5955-proof-of-concept.stat
        9 kB
        Dag H. Wanvik
      43. derby-5955-proof-of-concept.diff
        303 kB
        Dag H. Wanvik

        Issue Links

          Activity

          Hide
          ASF subversion and git services added a comment -

          Commit 1525061 from Myrna van Lunteren in branch 'code/trunk'
          [ https://svn.apache.org/r1525061 ]

          DERBY-6338; Remove Profile attribute from jar file manifests
          removing the Profile=compact2 lines added with DERBY-5955.

          Show
          ASF subversion and git services added a comment - Commit 1525061 from Myrna van Lunteren in branch 'code/trunk' [ https://svn.apache.org/r1525061 ] DERBY-6338 ; Remove Profile attribute from jar file manifests removing the Profile=compact2 lines added with DERBY-5955 .
          Hide
          Rick Hillegas added a comment -

          Thanks, Dag. These changes look good to me.

          Show
          Rick Hillegas added a comment - Thanks, Dag. These changes look good to me.
          Hide
          Dag H. Wanvik added a comment -

          Thanks, Rick, I agree it is a bit hard to read. Attached javadoc followup patch #2, committed as svn 1441869.

          Show
          Dag H. Wanvik added a comment - Thanks, Rick, I agree it is a bit hard to read. Attached javadoc followup patch #2, committed as svn 1441869.
          Hide
          Rick Hillegas added a comment -

          Thanks, Dag. These changes look good. One additional refinement might be possible:

          In the overview page for the JDBC4 version of org.apache.derby.jdbc, the summaries for the old datasources are formatted oddly and contain too much information. I believe this is caused by the fact that the summary table is generated by the javadoc tool. For each class it makes a summary comment consisting of everything in the class header comment up to the first period. I think the summaries for these classes would look more like the summaries for the other classes if the first period were put after the phrase "full Java SE 8". Then there's the odd formatting of the list which is included in the summary comment: the two lines of the list are appended and it's hard to parse sense out of the result. I don't know how to get a readable summary line and preserve the original list. You might consider collapsing the list into the preceding sentence in order to make the summary more readable. Thanks.

          Show
          Rick Hillegas added a comment - Thanks, Dag. These changes look good. One additional refinement might be possible: In the overview page for the JDBC4 version of org.apache.derby.jdbc, the summaries for the old datasources are formatted oddly and contain too much information. I believe this is caused by the fact that the summary table is generated by the javadoc tool. For each class it makes a summary comment consisting of everything in the class header comment up to the first period. I think the summaries for these classes would look more like the summaries for the other classes if the first period were put after the phrase "full Java SE 8". Then there's the odd formatting of the list which is included in the summary comment: the two lines of the list are appended and it's hard to parse sense out of the result. I don't know how to get a readable summary line and preserve the original list. You might consider collapsing the list into the preceding sentence in order to make the summary more readable. Thanks.
          Hide
          Dag H. Wanvik added a comment -

          Committed the javadoc followup patch at svn r1441327.

          Show
          Dag H. Wanvik added a comment - Committed the javadoc followup patch at svn r1441327.
          Hide
          Dag H. Wanvik added a comment -

          Thanks, Rick. Attaching patch derby-5955-javadoc-followup to include the improved wording for JDBC 4.2/Java 8.

          Show
          Dag H. Wanvik added a comment - Thanks, Rick. Attaching patch derby-5955-javadoc-followup to include the improved wording for JDBC 4.2/Java 8.
          Hide
          Rick Hillegas added a comment -

          Thanks for checking in those changes, Dag. Some comments on the public api javadoc:

          --------------------------------

          ClientConnectionPoolDataSource
          ClientDataSource
          ClientXADataSource
          EmbeddedConnectionPoolDataSource
          EmbeddedDataSource
          EmbeddedXADataSource

          "Java SE 7 og higher" -> "Java SE 7 or higher"

          --------------------------------

          ClientConnectionPoolDataSource40
          ClientDataSource40
          ClientXADataSource40
          EmbeddedConnectionPoolDataSource40
          EmbeddedDataSource40
          EmbeddedXADataSource40

          Replace "running on full Java SE 7, corresponding to JDBC 4.1." onward with this:

          "running on the following platforms:

          o JDBC 4.1 - Java SE 7
          o JDBC 4.2 - full Java SE 8

          Use $alternativeCP2DataSource if your application runs on Java 8 compact profile 2.

          Use $alternativeJDBC4.0DataSource if your application runs on the following platforms:

          o JDBC 4.0 - Java SE 6
          o JDBC 3.0 - J2SE 5.0"

          --------------------------------

          I think that the above changes will fix the package overview for the jdbc4 version of org.apache.derby.jdbc. Right now the jdbc 4 DataSources only say that they are appropriate for Java SE 7. After the above changes, those DataSources should indicate that they are also appropriate for Java SE 8.

          Thanks,
          -Rick

          Show
          Rick Hillegas added a comment - Thanks for checking in those changes, Dag. Some comments on the public api javadoc: -------------------------------- ClientConnectionPoolDataSource ClientDataSource ClientXADataSource EmbeddedConnectionPoolDataSource EmbeddedDataSource EmbeddedXADataSource "Java SE 7 og higher" -> "Java SE 7 or higher" -------------------------------- ClientConnectionPoolDataSource40 ClientDataSource40 ClientXADataSource40 EmbeddedConnectionPoolDataSource40 EmbeddedDataSource40 EmbeddedXADataSource40 Replace "running on full Java SE 7, corresponding to JDBC 4.1." onward with this: "running on the following platforms: o JDBC 4.1 - Java SE 7 o JDBC 4.2 - full Java SE 8 Use $alternativeCP2DataSource if your application runs on Java 8 compact profile 2. Use $alternativeJDBC4.0DataSource if your application runs on the following platforms: o JDBC 4.0 - Java SE 6 o JDBC 3.0 - J2SE 5.0" -------------------------------- I think that the above changes will fix the package overview for the jdbc4 version of org.apache.derby.jdbc. Right now the jdbc 4 DataSources only say that they are appropriate for Java SE 7. After the above changes, those DataSources should indicate that they are also appropriate for Java SE 8. Thanks, -Rick
          Hide
          Dag H. Wanvik added a comment -

          Thanks, Rick. I guess the patch application failed due to the data source rename operation. Committed derby-5955-rename as svn 1440262 and derby-5955-javadoc as svn 1440264. I am resolving this issue since all planned work is done, except documentation. I am removing the "release note needed" flag since existing APIs are not affected.

          Show
          Dag H. Wanvik added a comment - Thanks, Rick. I guess the patch application failed due to the data source rename operation. Committed derby-5955-rename as svn 1440262 and derby-5955-javadoc as svn 1440264. I am resolving this issue since all planned work is done, except documentation. I am removing the "release note needed" flag since existing APIs are not affected.
          Hide
          Rick Hillegas added a comment -

          Thanks for the patches, Dag. I resync'd my subversion client to the head of trunk and tried to apply derby-5955-rename. I bailed out after I got this error:

          The next patch would delete the file a/java/client/org/apache/derby/jdbc/NonJNDIClientConnectionPoolDataSource40.java,
          which does not exist! Assume -R? [n]

          I think that it's ok to remove ClientBaseDataSource from the public api. There shouldn't be a backward compatibility problem as long as the class itself hangs around. I might feel differently if the meaning of its constants were documented...but the constants are declared without any header comments and no-one has complained about this in seven years.

          Thanks,
          -Rick

          Show
          Rick Hillegas added a comment - Thanks for the patches, Dag. I resync'd my subversion client to the head of trunk and tried to apply derby-5955-rename. I bailed out after I got this error: The next patch would delete the file a/java/client/org/apache/derby/jdbc/NonJNDIClientConnectionPoolDataSource40.java, which does not exist! Assume -R? [n] I think that it's ok to remove ClientBaseDataSource from the public api. There shouldn't be a backward compatibility problem as long as the class itself hangs around. I might feel differently if the meaning of its constants were documented...but the constants are declared without any header comments and no-one has complained about this in seven years. Thanks, -Rick
          Hide
          Dag H. Wanvik added a comment -

          Uploading patch derby-5955-javadoc which builds on derby-5955-rename. (You need to apply the rename patch before attempting to apply the javadoc one).

          The patch updates the Javadoc as suggested by Rick, plus moves the ClientDriver to jdbc3 docs only, and adding ClientDriver40 to the jdbc4 docs. I also removed the class ClientBaseDataSource from the Javadoc; do we need it?

          Show
          Dag H. Wanvik added a comment - Uploading patch derby-5955-javadoc which builds on derby-5955-rename. (You need to apply the rename patch before attempting to apply the javadoc one). The patch updates the Javadoc as suggested by Rick, plus moves the ClientDriver to jdbc3 docs only, and adding ClientDriver40 to the jdbc4 docs. I also removed the class ClientBaseDataSource from the Javadoc; do we need it?
          Hide
          Dag H. Wanvik added a comment -

          Uploading derby-5955-rename, which changes the prefix of the new data sources from "NonJNDI" to "Basic", cf. earlier discussion on this issue.

          Show
          Dag H. Wanvik added a comment - Uploading derby-5955-rename, which changes the prefix of the new data sources from "NonJNDI" to "Basic", cf. earlier discussion on this issue.
          Hide
          Dag H. Wanvik added a comment - - edited

          Committed patch make-tests-run-03 as svn 1438035, including changes as suggested in Knut's item 1) above.

          Show
          Dag H. Wanvik added a comment - - edited Committed patch make-tests-run-03 as svn 1438035, including changes as suggested in Knut's item 1) above.
          Hide
          Dag H. Wanvik added a comment -

          Committed patch derby-5955-add-cp2-to-jars at svn 1437995.

          Show
          Dag H. Wanvik added a comment - Committed patch derby-5955-add-cp2-to-jars at svn 1437995.
          Hide
          Dag H. Wanvik added a comment -

          Right, that's an easy fix, I'll do that.

          Re: 3) I think it is because in DataSourceSerializationTest, we explicit reference JNDI itself, cf.

          Method getFactoryClassName =
          Class.forName("javax.naming.Reference").getMethod(
          "getFactoryClassName", null);

          whereas in Wrapper41DataSource we only reference other Derby classes dependent on JNDI. Probably it depends on how aggressively the classloader loads missing, but known, classes.

          Regressions passed on CP2 with patch make-tests-run-03. For the record, I changed from building CP2 as 64 bits JRE (Linux), to a 32 bits JRE, as the early access versions of Java 8 VM had an issue with metaspace overflow in lang._Suite.

          Show
          Dag H. Wanvik added a comment - Right, that's an easy fix, I'll do that. Re: 3) I think it is because in DataSourceSerializationTest, we explicit reference JNDI itself, cf. Method getFactoryClassName = Class.forName("javax.naming.Reference").getMethod( "getFactoryClassName", null); whereas in Wrapper41DataSource we only reference other Derby classes dependent on JNDI. Probably it depends on how aggressively the classloader loads missing, but known, classes. Regressions passed on CP2 with patch make-tests-run-03. For the record, I changed from building CP2 as 64 bits JRE (Linux), to a 32 bits JRE, as the early access versions of Java 8 VM had an issue with metaspace overflow in lang._Suite.
          Hide
          Knut Anders Hatlen added a comment -

          Thanks, Dag. Re 1): I was referring to DataSourceSerializationTest, which has code similar to this in many test cases:

          + if (JDBC.vmSupportsJNDI())

          { + final String EMBEDDED_CLASS = "EmbeddedDataSource"; + deSerializeDs(EMBEDDED_CLASS, VERSION_10_0_2_1); + deSerializeDs(EMBEDDED_CLASS, VERSION_10_1_3_1); + deSerializeDs(EMBEDDED_CLASS, VERSION_10_2_2_0); + deSerializeDs(EMBEDDED_CLASS, VERSION_10_3_2_1); + deSerializeDs(EMBEDDED_CLASS, VERSION_10_10_1_0); + deSerializeDs(EMBEDDED_CLASS + _40Suffix, VERSION_10_10_1_0); + }

          else

          { + final String EMBEDDED_CLASS = "NonJNDIEmbeddedDataSource40"; + deSerializeDs(EMBEDDED_CLASS, VERSION_10_10_1_0); + }

          I was thinking that it might work in JNDI environment if the else branch was made unconditional. It's not that simple in other tests, so I'm not suggesting that we run all DataSource tests with both variants on platforms supporting JNDI. Just that we have some minimal sanity checking if it doesn't require too much effort.

          Show
          Knut Anders Hatlen added a comment - Thanks, Dag. Re 1): I was referring to DataSourceSerializationTest, which has code similar to this in many test cases: + if (JDBC.vmSupportsJNDI()) { + final String EMBEDDED_CLASS = "EmbeddedDataSource"; + deSerializeDs(EMBEDDED_CLASS, VERSION_10_0_2_1); + deSerializeDs(EMBEDDED_CLASS, VERSION_10_1_3_1); + deSerializeDs(EMBEDDED_CLASS, VERSION_10_2_2_0); + deSerializeDs(EMBEDDED_CLASS, VERSION_10_3_2_1); + deSerializeDs(EMBEDDED_CLASS, VERSION_10_10_1_0); + deSerializeDs(EMBEDDED_CLASS + _40Suffix, VERSION_10_10_1_0); + } else { + final String EMBEDDED_CLASS = "NonJNDIEmbeddedDataSource40"; + deSerializeDs(EMBEDDED_CLASS, VERSION_10_10_1_0); + } I was thinking that it might work in JNDI environment if the else branch was made unconditional. It's not that simple in other tests, so I'm not suggesting that we run all DataSource tests with both variants on platforms supporting JNDI. Just that we have some minimal sanity checking if it doesn't require too much effort.
          Hide
          Dag H. Wanvik added a comment -

          Thanks, Knut. Re 1): Yes, but it would require some biggish changes to the way the data sources are selected in the current tests, which use TestConfiguration#getJDBCClient which in turn return the "suitable" data sources for the current configuration, which for a full SE would be the JNDI full ones. I'll see if there is a way to finesse this in (some) of the most important tests.

          Re 2): Ah yes, thanks, a gotcha. In this case the inclusive semantics hold. I think I want to rename #vmSupportsJSR169 to #vmSupportsOnlyJSR169 to make this difference clear.

          Re 3): It could be I inserted too much reflection here, I'll check.

          Show
          Dag H. Wanvik added a comment - Thanks, Knut. Re 1): Yes, but it would require some biggish changes to the way the data sources are selected in the current tests, which use TestConfiguration#getJDBCClient which in turn return the "suitable" data sources for the current configuration, which for a full SE would be the JNDI full ones. I'll see if there is a way to finesse this in (some) of the most important tests. Re 2): Ah yes, thanks, a gotcha. In this case the inclusive semantics hold. I think I want to rename #vmSupportsJSR169 to #vmSupportsOnlyJSR169 to make this difference clear. Re 3): It could be I inserted too much reflection here, I'll check.
          Hide
          Knut Anders Hatlen added a comment -

          Thanks, Dag. The changes in the make-tests-run-03 patch look good to me. Some further comments and questions:

          DataSourceSerializationTest.java:

          • Would it make sense to test the non-JNDI data sources also if the JVM does support JNDI? Then those who run tests in environments that do support JNDI might notice earlier if they've broken the non-JNDI data sources.
          • I think this check is too broad and unintentionally disables testing of JDBC 4 data sources on platforms that support JDBC 4 (vmSupportsJDBC3() returns true in JDBC 4 environments):

          if (JDBC.vmSupportsJDBC3() && className.contains("40"))

          { // Running old Java, bail out if JDBC4 return; }
          • Some JNDI code in deSerializeDs() had to be rewritten using reflection to prevent the JVM from trying to load JNDI classes even if the code was never executed. Out of curiosity, do you know what makes reflection necessary in this code and not in, for example, Wrapper41DataSource, which accesses the JNDI data sources without reflection?
          Show
          Knut Anders Hatlen added a comment - Thanks, Dag. The changes in the make-tests-run-03 patch look good to me. Some further comments and questions: DataSourceSerializationTest.java: Would it make sense to test the non-JNDI data sources also if the JVM does support JNDI? Then those who run tests in environments that do support JNDI might notice earlier if they've broken the non-JNDI data sources. I think this check is too broad and unintentionally disables testing of JDBC 4 data sources on platforms that support JDBC 4 (vmSupportsJDBC3() returns true in JDBC 4 environments): if (JDBC.vmSupportsJDBC3() && className.contains("40")) { // Running old Java, bail out if JDBC4 return; } Some JNDI code in deSerializeDs() had to be rewritten using reflection to prevent the JVM from trying to load JNDI classes even if the code was never executed. Out of curiosity, do you know what makes reflection necessary in this code and not in, for example, Wrapper41DataSource, which accesses the JNDI data sources without reflection?
          Hide
          Dag H. Wanvik added a comment -

          Attaching a new version of the tests patch, "derby-5955-make-tests-run-03.diff", which makes the following change:

          refactor JDBC#supportsNonJNDI to #supportsJNDI

          It turned out there was few if any cases causing problems for the semantics change, so the positive formulation is better.

          Rerunning regressions.

          Show
          Dag H. Wanvik added a comment - Attaching a new version of the tests patch, "derby-5955-make-tests-run-03.diff", which makes the following change: refactor JDBC#supportsNonJNDI to #supportsJNDI It turned out there was few if any cases causing problems for the semantics change, so the positive formulation is better. Rerunning regressions.
          Hide
          Kristian Waagan added a comment -

          Thanks, Dag.

          I wasn't worried about you undoing my patches, I was just wondering if the situation had changed because of your changes From what I gather, DERBY-4719 still describe existing problems (albeit of low severity).
          In any case, it is good that the newly introduced data sources don't bring in yet another set of quirks and behaviors.

          Show
          Kristian Waagan added a comment - Thanks, Dag. I wasn't worried about you undoing my patches, I was just wondering if the situation had changed because of your changes From what I gather, DERBY-4719 still describe existing problems (albeit of low severity). In any case, it is good that the newly introduced data sources don't bring in yet another set of quirks and behaviors.
          Hide
          Dag H. Wanvik added a comment - - edited

          Hi Kristian, thanks for alerting me. No, I don't think so. These regression tests run as before on both Java SE and on CP2, and as far as I can se I haven't undone any of your code from your patches in DERBY-4719 or DERBY-4067, even though the code has changed location, e.g. the guts you added to getXAConnection has now moved to ClientBaseDataSourceRoot#getXAConnectionMinion, so it is shareable between tol "old" DSes and the new ones.

          Show
          Dag H. Wanvik added a comment - - edited Hi Kristian, thanks for alerting me. No, I don't think so. These regression tests run as before on both Java SE and on CP2, and as far as I can se I haven't undone any of your code from your patches in DERBY-4719 or DERBY-4067 , even though the code has changed location, e.g. the guts you added to getXAConnection has now moved to ClientBaseDataSourceRoot#getXAConnectionMinion, so it is shareable between tol "old" DSes and the new ones.
          Hide
          Kristian Waagan added a comment -

          Hi Dag,

          Thanks for working on this
          I haven't followed the work closely, but does your work affect DERBY-4719 in any way?

          Show
          Kristian Waagan added a comment - Hi Dag, Thanks for working on this I haven't followed the work closely, but does your work affect DERBY-4719 in any way?
          Hide
          Dag H. Wanvik added a comment - - edited

          Thanks, Knut and Rick!

          Uploading a new patch revision; derby-5955-make-tests-run-02. I ran this on full Java SE 1.5 to check any issues with JDBC 3/4 in the modified tests, I had to make one change to accommodate for that (DataSourceSerializationTest#deSerializeDs). I also refreshed my JEP-161 source repo and build with the latest sources of Java 8 CP2 and ran the the regression tests without errors (with the addition of derby-5955-add-cp2-to-jars).

          Addressed Knut's code comments as follows:

          > - The patch seems to add the svn:executable property to the serialized
          > data files. Is that needed?

          No, they appeared automatically when I added them. I found I had to remove the property explicitly; done.

          > - I'm assuming the XADataSource created by ij is only used internally
          > and never returned to the user? And that ij doesn't need the JNDI
          > functionality? If so, maybe it should always attempt to use the
          > non-JNDI variant, so that it doesn't load javax.naming classes
          > unnecessarily?

          True and true. I think I'll keep the differentiation: since this functionality is used for testing the data sources, I fear it could as an (unpleasant) surprise that ij used the less capable data source on a full SE platform. They do share much of the code, but..

          >
          > - In SerializeDataSources.java: Might be clearer to change if
          > (!(dsClassName.indexOf("NonJNDI") > 0)) ---> if
          > (!dsClassName.contains("NonJNDI"))

          Agreed, done.

          >
          > - The name of the JDBC.vmSupportsNonJNDI() method is a bit misleading,
          > as it returns false for some platforms that do support the NonJNDI
          > data source (for example, Java 7). Having a vmSupportsJNDI() method
          > instead might be less confusing.

          This method pattern is a bit murky; there is precedence for using the "supports<Feature>" methods both ways here; JDBC.vmSupportJSR169 is exclusive; i.e. more capable runtimes return false. JDBC.vmSupportJDBC3 is inclusive; i.e. more capable runtimes return true. I agree in the inclusive semantics are more intuitive.

          I can change this, but then I'd need to add a guard at usage sites to make sure we don't use JDBC 4 level non-JNDI data sources under JDBC3 level runtimes too (CDC/JSR169). I'll think a bit about the best way to do this.

          > - In Wrapper41DataSource, we first check for instanceof
          > NonJNDIEmbeddedDataSource40 and then
          > NonJNDIEmbeddedConnectionPoolDataSource40 and
          > NonJNDIEmbeddedXADataSource40. Since the latter two classes extend
          > NonJNDIEmbeddedDataSource40, only the first check will ever
          > succeed. So I think the _nonJNDIecpds and _nonJNDIexads fields can
          > be removed. And ditto for the non-JNDI client data sources.

          Correct, fixed, thanks! The new data sources are different from the old ones in this respect.

          Rick, I'll address the Javadoc changes you propose in a follow up patch.

          Show
          Dag H. Wanvik added a comment - - edited Thanks, Knut and Rick! Uploading a new patch revision; derby-5955-make-tests-run-02. I ran this on full Java SE 1.5 to check any issues with JDBC 3/4 in the modified tests, I had to make one change to accommodate for that (DataSourceSerializationTest#deSerializeDs). I also refreshed my JEP-161 source repo and build with the latest sources of Java 8 CP2 and ran the the regression tests without errors (with the addition of derby-5955-add-cp2-to-jars). Addressed Knut's code comments as follows: > - The patch seems to add the svn:executable property to the serialized > data files. Is that needed? No, they appeared automatically when I added them. I found I had to remove the property explicitly; done. > - I'm assuming the XADataSource created by ij is only used internally > and never returned to the user? And that ij doesn't need the JNDI > functionality? If so, maybe it should always attempt to use the > non-JNDI variant, so that it doesn't load javax.naming classes > unnecessarily? True and true. I think I'll keep the differentiation: since this functionality is used for testing the data sources, I fear it could as an (unpleasant) surprise that ij used the less capable data source on a full SE platform. They do share much of the code, but.. > > - In SerializeDataSources.java: Might be clearer to change if > (!(dsClassName.indexOf("NonJNDI") > 0)) ---> if > (!dsClassName.contains("NonJNDI")) Agreed, done. > > - The name of the JDBC.vmSupportsNonJNDI() method is a bit misleading, > as it returns false for some platforms that do support the NonJNDI > data source (for example, Java 7). Having a vmSupportsJNDI() method > instead might be less confusing. This method pattern is a bit murky; there is precedence for using the "supports<Feature>" methods both ways here; JDBC.vmSupportJSR169 is exclusive; i.e. more capable runtimes return false. JDBC.vmSupportJDBC3 is inclusive; i.e. more capable runtimes return true. I agree in the inclusive semantics are more intuitive. I can change this, but then I'd need to add a guard at usage sites to make sure we don't use JDBC 4 level non-JNDI data sources under JDBC3 level runtimes too (CDC/JSR169). I'll think a bit about the best way to do this. > - In Wrapper41DataSource, we first check for instanceof > NonJNDIEmbeddedDataSource40 and then > NonJNDIEmbeddedConnectionPoolDataSource40 and > NonJNDIEmbeddedXADataSource40. Since the latter two classes extend > NonJNDIEmbeddedDataSource40, only the first check will ever > succeed. So I think the _nonJNDIecpds and _nonJNDIexads fields can > be removed. And ditto for the non-JNDI client data sources. Correct, fixed, thanks! The new data sources are different from the old ones in this respect. Rick, I'll address the Javadoc changes you propose in a follow up patch.
          Hide
          Rick Hillegas added a comment -

          Hi Dag,

          Thanks for all of this great work. A big +1 to what you've done so far.

          Since you're working on tests now, I assume you're basically done with restructuring the DataSources in the product. I have built the javadoc and looked at the DataSource public api. It looks to me like the correct classes are included in the public api. In addition, it looks like the DataSources implement the expected interfaces. I see that you've introduced a number of interfaces which don't appear in the public api. It's too bad that they are still mentioned by the interface lists for the included DataSources--but I don't know how to make the cruft disappear from those lists.

          When you come up for air, it would be good to give users guidance about which DataSource best fits their environment. I think these are the environments we can expect:

          o Embedded application running on CDC/FP 1.1
          o Embedded application running on Java 5.
          o Embedded application running on Java 6 and 7
          o Embedded application running on full Java 8
          o Embedded application running on CP2, the small device configuration for Java 8.
          o Client/server application running on Java 5.
          o Client/server application running on Java 6 and 7
          o Client/server application running on full Java 8
          o Client/server application running on CP2, the small device configuration for Java 8.

          The following adjustments to the public api documentation make sense to me:

          o Adjust the wording of the lead sentence in the javadoc header for every DataSource, indicating which of the above environments it fits. The first sentence appears in the package overview, in the generated table of classes included in the package.

          o Adjust the package overview html, adding the new DataSources to the list of DataSources. Probably you will need 2 more blocks of DataSources, parallel to the existing 2 blocks.

          Thanks!
          -Rick

          Show
          Rick Hillegas added a comment - Hi Dag, Thanks for all of this great work. A big +1 to what you've done so far. Since you're working on tests now, I assume you're basically done with restructuring the DataSources in the product. I have built the javadoc and looked at the DataSource public api. It looks to me like the correct classes are included in the public api. In addition, it looks like the DataSources implement the expected interfaces. I see that you've introduced a number of interfaces which don't appear in the public api. It's too bad that they are still mentioned by the interface lists for the included DataSources--but I don't know how to make the cruft disappear from those lists. When you come up for air, it would be good to give users guidance about which DataSource best fits their environment. I think these are the environments we can expect: o Embedded application running on CDC/FP 1.1 o Embedded application running on Java 5. o Embedded application running on Java 6 and 7 o Embedded application running on full Java 8 o Embedded application running on CP2, the small device configuration for Java 8. o Client/server application running on Java 5. o Client/server application running on Java 6 and 7 o Client/server application running on full Java 8 o Client/server application running on CP2, the small device configuration for Java 8. The following adjustments to the public api documentation make sense to me: o Adjust the wording of the lead sentence in the javadoc header for every DataSource, indicating which of the above environments it fits. The first sentence appears in the package overview, in the generated table of classes included in the package. o Adjust the package overview html, adding the new DataSources to the list of DataSources. Probably you will need 2 more blocks of DataSources, parallel to the existing 2 blocks. Thanks! -Rick
          Hide
          Knut Anders Hatlen added a comment -

          My comments to the make-tests-run-01 patch:

          • The patch seems to add the svn:executable property to the serialized data files. Is that needed?
          • I'm assuming the XADataSource created by ij is only used internally and never returned to the user? And that ij doesn't need the JNDI functionality? If so, maybe it should always attempt to use the non-JNDI variant, so that it doesn't load javax.naming classes unnecessarily?
          • In SerializeDataSources.java: Might be clearer to change if (!(dsClassName.indexOf("NonJNDI") > 0)) ---> if (!dsClassName.contains("NonJNDI"))
          • The name of the JDBC.vmSupportsNonJNDI() method is a bit misleading, as it returns false for some platforms that do support the NonJNDI data source (for example, Java 7). Having a vmSupportsJNDI() method instead might be less confusing.
          • In Wrapper41DataSource, we first check for instanceof NonJNDIEmbeddedDataSource40 and then NonJNDIEmbeddedConnectionPoolDataSource40 and NonJNDIEmbeddedXADataSource40. Since the latter two classes extend NonJNDIEmbeddedDataSource40, only the first check will ever succeed. So I think the _nonJNDIecpds and _nonJNDIexads fields can be removed. And ditto for the non-JNDI client data sources.
          Show
          Knut Anders Hatlen added a comment - My comments to the make-tests-run-01 patch: The patch seems to add the svn:executable property to the serialized data files. Is that needed? I'm assuming the XADataSource created by ij is only used internally and never returned to the user? And that ij doesn't need the JNDI functionality? If so, maybe it should always attempt to use the non-JNDI variant, so that it doesn't load javax.naming classes unnecessarily? In SerializeDataSources.java: Might be clearer to change if (!(dsClassName.indexOf("NonJNDI") > 0)) ---> if (!dsClassName.contains("NonJNDI")) The name of the JDBC.vmSupportsNonJNDI() method is a bit misleading, as it returns false for some platforms that do support the NonJNDI data source (for example, Java 7). Having a vmSupportsJNDI() method instead might be less confusing. In Wrapper41DataSource, we first check for instanceof NonJNDIEmbeddedDataSource40 and then NonJNDIEmbeddedConnectionPoolDataSource40 and NonJNDIEmbeddedXADataSource40. Since the latter two classes extend NonJNDIEmbeddedDataSource40, only the first check will ever succeed. So I think the _nonJNDIecpds and _nonJNDIexads fields can be removed. And ditto for the non-JNDI client data sources.
          Hide
          Dag H. Wanvik added a comment -

          Patch details:

          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/ClientConnectionPoolDataSource-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/ClientConnectionPoolDataSource40-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/ClientDataSource-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/ClientDataSource40-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/ClientXADataSource-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/ClientXADataSource40-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/EmbeddedConnectionPoolDataSource-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/EmbeddedConnectionPoolDataSource40-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/EmbeddedDataSource-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/EmbeddedDataSource40-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/EmbeddedXADataSource-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/EmbeddedXADataSource40-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/NonJNDIClientConnectionPoolDataSource40-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/NonJNDIClientDataSource40-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/NonJNDIClientXADataSource40-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/NonJNDIEmbeddedConnectionPoolDataSource40-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/NonJNDIEmbeddedDataSource40-10_10_1_0.ser
          A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/NonJNDIEmbeddedXADataSource40-10_10_1_0.ser

          New serialized data source for Derby 10_10, including such for the new data sources. These are binary files and not visible in the patch diff file. See attached file derby-5955-ser-b.zip.

          M java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/SerializeDataSources.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DataSourceSerializationTest.java

          Updated versions which knows about the new release and also non-jndi data source (so it doesn't try to get a naming reference on deserializing).
          It also produces and tests versions for the JDCB >= 4.0 level data sources which were skipped before, e.g. "ClientDataSource40-10_10_1_0.ser".

          M java/testing/org/apache/derbyTesting/junit/Derby.java
          M java/testing/org/apache/derbyTesting/junit/JDBC.java
          M java/testing/org/apache/derbyTesting/junit/JDBCClient.java

          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/Wrapper41DataSource.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ClientConnectionPoolDataSourceTest.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DataSourceTest.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/J2EEDataSourceTest.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun_Local_1Indexing.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun_Local_3.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun_Local_3_p3.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun_Local_3_p4.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun_Local_3_p6.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun_Local_Encrypted_1.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/SimplePerfTest.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/SimplePerfTest_Verify.java
          M java/testing/org/apache/derbyTesting/junit/SecurityManagerSetup.java

          Add functionality to make tests run also on the new data sources, including reflection for both kinds of data sources to avoid a) execution on compact profile platform top gag on classes requiring JNDI, and b) to avoid a Java 5 SE run to gag on the class format of the compact platform data source classes (all of which have suffix *40). Note also the heavy use of the new ds interfaces here.

          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DataSourceReferenceTest.java

          Skip this test for non-JNDI data sources since "Reference" in the name here is javax.naming.Reference (part of JNDI).

          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC4FromJDBC3DataSourceTest.java

          Skip.

          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/InvalidLDAPServerAuthenticationTest.java

          Adapt to failure under CP2; can't load authenticate with LDAP if no JNDI.

          M java/tools/org/apache/derby/impl/tools/ij/ij.jj
          M java/tools/org/apache/derby/impl/tools/ij/xaHelper.java

          Changes to ij's xa capability to support the new data sources also.

          Show
          Dag H. Wanvik added a comment - Patch details: A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/ClientConnectionPoolDataSource-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/ClientConnectionPoolDataSource40-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/ClientDataSource-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/ClientDataSource40-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/ClientXADataSource-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/ClientXADataSource40-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/EmbeddedConnectionPoolDataSource-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/EmbeddedConnectionPoolDataSource40-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/EmbeddedDataSource-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/EmbeddedDataSource40-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/EmbeddedXADataSource-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/EmbeddedXADataSource40-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/NonJNDIClientConnectionPoolDataSource40-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/NonJNDIClientDataSource40-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/NonJNDIClientXADataSource40-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/NonJNDIEmbeddedConnectionPoolDataSource40-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/NonJNDIEmbeddedDataSource40-10_10_1_0.ser A java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/NonJNDIEmbeddedXADataSource40-10_10_1_0.ser New serialized data source for Derby 10_10, including such for the new data sources. These are binary files and not visible in the patch diff file. See attached file derby-5955-ser-b.zip. M java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/SerializeDataSources.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DataSourceSerializationTest.java Updated versions which knows about the new release and also non-jndi data source (so it doesn't try to get a naming reference on deserializing). It also produces and tests versions for the JDCB >= 4.0 level data sources which were skipped before, e.g. "ClientDataSource40-10_10_1_0.ser". M java/testing/org/apache/derbyTesting/junit/Derby.java M java/testing/org/apache/derbyTesting/junit/JDBC.java M java/testing/org/apache/derbyTesting/junit/JDBCClient.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/Wrapper41DataSource.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ClientConnectionPoolDataSourceTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DataSourceTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/J2EEDataSourceTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun_Local_1Indexing.java M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun_Local_3.java M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun_Local_3_p3.java M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun_Local_3_p4.java M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun_Local_3_p6.java M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun_Local_Encrypted_1.java M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/SimplePerfTest.java M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/SimplePerfTest_Verify.java M java/testing/org/apache/derbyTesting/junit/SecurityManagerSetup.java Add functionality to make tests run also on the new data sources, including reflection for both kinds of data sources to avoid a) execution on compact profile platform top gag on classes requiring JNDI, and b) to avoid a Java 5 SE run to gag on the class format of the compact platform data source classes (all of which have suffix *40). Note also the heavy use of the new ds interfaces here. M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DataSourceReferenceTest.java Skip this test for non-JNDI data sources since "Reference" in the name here is javax.naming.Reference (part of JNDI). M java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/JDBC4FromJDBC3DataSourceTest.java Skip. M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/InvalidLDAPServerAuthenticationTest.java Adapt to failure under CP2; can't load authenticate with LDAP if no JNDI. M java/tools/org/apache/derby/impl/tools/ij/ij.jj M java/tools/org/apache/derby/impl/tools/ij/xaHelper.java Changes to ij's xa capability to support the new data sources also.
          Hide
          Dag H. Wanvik added a comment - - edited

          Uploading patch derby-5955-make-tests-run-01. This patch only makes changes to the tests to make them run on a platform with Profile == compact2.

          I have verified these changes make the regressions run without error on my early build of the JEP 161 codeline (with patch derby-5955-add-cp2-to-jars) and also that the tests still run ok on an ordinary Java SE platform.

          There is, however, one little product change: ij has undocumented functionality to support script based testing of XA, cf xaHelper#getXADataSource. This code has now been changed to work even when JNDI is absent by using the new data sources.

          The tests for serailizable data sources introduce new binary checked in lobs, so to test this patch you need to either generate the new lobs yourself (cd to directory java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources, then run org.apache.derbyTesting.functionTests.testData.serializedDataSources.SerializeDataSources with no arguments. this will produce the new lobs containing serialized data sources at level 10_10), or you can download the zip bundle I attach, "derby-5955-ser-b.zip" and unzip it from the top level in the repo. See also DERBY-5997.

          I don't expect people to build and test Java 8 with the new profiles code; please check the patch for correctness as to existing tests not being broken by this patch. Thanks!

          Show
          Dag H. Wanvik added a comment - - edited Uploading patch derby-5955-make-tests-run-01. This patch only makes changes to the tests to make them run on a platform with Profile == compact2. I have verified these changes make the regressions run without error on my early build of the JEP 161 codeline (with patch derby-5955-add-cp2-to-jars) and also that the tests still run ok on an ordinary Java SE platform. There is, however, one little product change: ij has undocumented functionality to support script based testing of XA, cf xaHelper#getXADataSource. This code has now been changed to work even when JNDI is absent by using the new data sources. The tests for serailizable data sources introduce new binary checked in lobs, so to test this patch you need to either generate the new lobs yourself (cd to directory java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources, then run org.apache.derbyTesting.functionTests.testData.serializedDataSources.SerializeDataSources with no arguments. this will produce the new lobs containing serialized data sources at level 10_10), or you can download the zip bundle I attach, "derby-5955-ser-b.zip" and unzip it from the top level in the repo. See also DERBY-5997 . I don't expect people to build and test Java 8 with the new profiles code; please check the patch for correctness as to existing tests not being broken by this patch. Thanks!
          Hide
          Dag H. Wanvik added a comment -

          Uploading patch derby-5955-add-cp2-to-jars.diff. This changes the top level build.xml to add a new attribute to MANIFEST.MF in Derby's jar files:

          Profile: compact2

          This will ensure that if Derby is ever attempted run on a less capable platform, i.e. compact1, java will issue an error informing the user that Derby requires at least compact2 level.

          Cf. this quite in http://openjdk.java.net/jeps/161:

          "jar — The JAR-file manifest specification will be extended with a new attribute which can be used to specify the minimum Profile required by the code in a JAR file."

          In the current code line, the format used is the one shown above.

          Show
          Dag H. Wanvik added a comment - Uploading patch derby-5955-add-cp2-to-jars.diff. This changes the top level build.xml to add a new attribute to MANIFEST.MF in Derby's jar files: Profile: compact2 This will ensure that if Derby is ever attempted run on a less capable platform, i.e. compact1, java will issue an error informing the user that Derby requires at least compact2 level. Cf. this quite in http://openjdk.java.net/jeps/161: "jar — The JAR-file manifest specification will be extended with a new attribute which can be used to specify the minimum Profile required by the code in a JAR file." In the current code line, the format used is the one shown above.
          Hide
          Knut Anders Hatlen added a comment -

          Thanks Dag. I think a "Basic" prefix would be fine. That prefix describes what the data sources are in a positive way, and it would allow us to preserve "simple" for data sources that implement less than required by the full JDBC specification.

          Show
          Knut Anders Hatlen added a comment - Thanks Dag. I think a "Basic" prefix would be fine. That prefix describes what the data sources are in a positive way, and it would allow us to preserve "simple" for data sources that implement less than required by the full JDBC specification.
          Hide
          Dag H. Wanvik added a comment -

          Committed patch derby-5955-new-non-jndi-ds-02 as svn 1432380.

          Show
          Dag H. Wanvik added a comment - Committed patch derby-5955-new-non-jndi-ds-02 as svn 1432380.
          Hide
          Dag H. Wanvik added a comment -

          You are right it will fail on Java 5 due to class load format, thanks. I've changed the patch (version 02 uploaded) to guard against too old JVM.

          While I agree with you that it would be better to have a more generic name for the reduced functionality data sources, e.g. "simple", I'm slightly worried that "overloading" the current EmbeddedSimpleDataSource naming with a different kind of "simple" in EmbeddedSimpleDataSource40. But maybe that's OK, since presumably we wouldn't see the JSR-169 one need to upgrade to "*40" status and won't have a naming clash later?

          Another option is to use another kind of naming hint, e.g. a "Basic-" prefix BasicEmbeddedDataSource40, BasicEmbeddedConnectionPoolDataSource40 etc.

          What do you think?

          Show
          Dag H. Wanvik added a comment - You are right it will fail on Java 5 due to class load format, thanks. I've changed the patch (version 02 uploaded) to guard against too old JVM. While I agree with you that it would be better to have a more generic name for the reduced functionality data sources, e.g. "simple", I'm slightly worried that "overloading" the current EmbeddedSimpleDataSource naming with a different kind of "simple" in EmbeddedSimpleDataSource40. But maybe that's OK, since presumably we wouldn't see the JSR-169 one need to upgrade to "*40" status and won't have a naming clash later? Another option is to use another kind of naming hint, e.g. a "Basic-" prefix BasicEmbeddedDataSource40, BasicEmbeddedConnectionPoolDataSource40 etc. What do you think?
          Hide
          Knut Anders Hatlen added a comment -

          The structure of the patch looks fine to me. Some small comments:

          • DataSourceTest now attempts to create a NonJNDIEmbeddedDataSource40 in one of the test cases. Does this work on Java 5, or do we need logic to skip it?
          • Naming of the new classes: Would it make sense to drop the NonJNDI prefix and instead follow the pattern of the JSR-169 DataSource by calling them simple data sources? Like EmbeddedSimpleDataSource40, EmbeddedSimpleConnectionPoolDataSource40, etc. By using "simple" we indicate that the data sources only have the minimal set of features, which may be clearer and more maintainable than enumerating the features that are left out. Feel free to check in the patch with the current names, though, as the names can be changed easily later if we find better ones.
          Show
          Knut Anders Hatlen added a comment - The structure of the patch looks fine to me. Some small comments: DataSourceTest now attempts to create a NonJNDIEmbeddedDataSource40 in one of the test cases. Does this work on Java 5, or do we need logic to skip it? Naming of the new classes: Would it make sense to drop the NonJNDI prefix and instead follow the pattern of the JSR-169 DataSource by calling them simple data sources? Like EmbeddedSimpleDataSource40, EmbeddedSimpleConnectionPoolDataSource40, etc. By using "simple" we indicate that the data sources only have the minimal set of features, which may be clearer and more maintainable than enumerating the features that are left out. Feel free to check in the patch with the current names, though, as the names can be changed easily later if we find better ones.
          Hide
          Dag H. Wanvik added a comment -

          Regressions ran ok modulo DERBY-6038 which is unrelated.

          Show
          Dag H. Wanvik added a comment - Regressions ran ok modulo DERBY-6038 which is unrelated.
          Hide
          Dag H. Wanvik added a comment - - edited

          Attaching patch derby-5955-new-non-jndi-ds-01. This introduces the six (three for each driver) new data sources that are not dependent on JNDI.

          Details:

          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DataSourceTest.java

          This includes a small sanity check by adding a test case to be run even on full Java SE.

          Adaptations of tests to make them run on a compact profile 2 JRE will follow later. The focus here is the new sources of the data source classes.

          Also it adds changes to the following files:

          M java/engine/org/apache/derby/iapi/services/info/JVMInfo.java

          Add utility method to determine if JNDI is available.

          M java/drda/org/apache/derby/impl/drda/XADatabase.java

          Make this class fall back to using the non-jndi version if running without JNDI.

          M java/engine/org/apache/derby/modules.properties

          Remove the requirement that JNDI classes be present for Derby to boot.

          M tools/jar/dnc.properties

          Add new data sources to client jar.

          M tools/jar/extraDBMSclasses.properties

          Add new data sources to embedded jar

          M tools/javadoc/publishedapi_jdbc4.ant

          Add new data source classes to published API.

          Running regressions.

          Show
          Dag H. Wanvik added a comment - - edited Attaching patch derby-5955-new-non-jndi-ds-01. This introduces the six (three for each driver) new data sources that are not dependent on JNDI. Details: M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DataSourceTest.java This includes a small sanity check by adding a test case to be run even on full Java SE. Adaptations of tests to make them run on a compact profile 2 JRE will follow later. The focus here is the new sources of the data source classes. Also it adds changes to the following files: M java/engine/org/apache/derby/iapi/services/info/JVMInfo.java Add utility method to determine if JNDI is available. M java/drda/org/apache/derby/impl/drda/XADatabase.java Make this class fall back to using the non-jndi version if running without JNDI. M java/engine/org/apache/derby/modules.properties Remove the requirement that JNDI classes be present for Derby to boot. M tools/jar/dnc.properties Add new data sources to client jar. M tools/jar/extraDBMSclasses.properties Add new data sources to embedded jar M tools/javadoc/publishedapi_jdbc4.ant Add new data source classes to published API. Running regressions.
          Hide
          Dag H. Wanvik added a comment -

          Thanks, Knut. Agreed. I committed derby-5955-client-restructure-02, but with a slight modification as shown in derby-5955-client-restructure-02-delta.diff. Svn rev. 1430648.

          Show
          Dag H. Wanvik added a comment - Thanks, Knut. Agreed. I committed derby-5955-client-restructure-02, but with a slight modification as shown in derby-5955-client-restructure-02-delta.diff. Svn rev. 1430648.
          Hide
          Knut Anders Hatlen added a comment -

          Thanks, Dag. Version 02 looks good to me. Minor nit: The patch makes addBeanProperties() static and adds a parameter so that a reference to this could be passed to it. It might be simpler to keep the method non-static and let it access this directly.

          Show
          Knut Anders Hatlen added a comment - Thanks, Dag. Version 02 looks good to me. Minor nit: The patch makes addBeanProperties() static and adds a parameter so that a reference to this could be passed to it. It might be simpler to keep the method non-static and let it access this directly.
          Hide
          Dag H. Wanvik added a comment - - edited

          Uploading version 02, introducing a new root class, ClientBaseDataSourceRoot to allow ClientBaseDataSource to get its "implements Referenceable" status back. Also refactored the beans "getProperties" methods into one, located in ClientBaseDataSourceRoot, specializations left in LogWriter#getProperties and ClientBaseDataSource#addBeanProperties repectively (usage sites).

          Rerunning regressions. [Update: all passed.]

          Show
          Dag H. Wanvik added a comment - - edited Uploading version 02, introducing a new root class, ClientBaseDataSourceRoot to allow ClientBaseDataSource to get its "implements Referenceable" status back. Also refactored the beans "getProperties" methods into one, located in ClientBaseDataSourceRoot, specializations left in LogWriter#getProperties and ClientBaseDataSource#addBeanProperties repectively (usage sites). Rerunning regressions. [Update: all passed.]
          Hide
          Dag H. Wanvik added a comment -

          Thanks, Knut. Yes, that's right, similar concerns apply here as to the API change on ClientBaseDataSource. I agreed with Rick on this and changed the embedded structure accordingly. So, I guess we'd better err on the side of caution here and introduce another base class as you suggest. I'll look into the sharing issue to see if we can remove that redundancy.

          Show
          Dag H. Wanvik added a comment - Thanks, Knut. Yes, that's right, similar concerns apply here as to the API change on ClientBaseDataSource. I agreed with Rick on this and changed the embedded structure accordingly. So, I guess we'd better err on the side of caution here and introduce another base class as you suggest. I'll look into the sharing issue to see if we can remove that redundancy.
          Hide
          Knut Anders Hatlen added a comment -

          The client patch changes ClientBaseDataSource (which is part of the public API) so that it doesn't implement javax.naming.Referenceable anymore. Rick expressed concern about that API change in an earlier comment, and I can't see that we reached consensus on that issue. In order to preserve the old API, we'd probably have to add a (non-public) parent class of ClientBaseDataSource with all the functionality of ClientBaseDataSource except the Referencable methods.

          Would it be possible to make LogWriter and ClientDataSource share the code that fetches all the bean properties of the data source?

          Apart from the above comments, I think the patch looks like a good cleanup.

          Show
          Knut Anders Hatlen added a comment - The client patch changes ClientBaseDataSource (which is part of the public API) so that it doesn't implement javax.naming.Referenceable anymore. Rick expressed concern about that API change in an earlier comment, and I can't see that we reached consensus on that issue. In order to preserve the old API, we'd probably have to add a (non-public) parent class of ClientBaseDataSource with all the functionality of ClientBaseDataSource except the Referencable methods. Would it be possible to make LogWriter and ClientDataSource share the code that fetches all the bean properties of the data source? Apart from the above comments, I think the patch looks like a good cleanup.
          Hide
          Dag H. Wanvik added a comment - - edited

          Regressions ran without error. I plan to commit this Tuesday morning if no objections arise.

          Show
          Dag H. Wanvik added a comment - - edited Regressions ran without error. I plan to commit this Tuesday morning if no objections arise.
          Hide
          Dag H. Wanvik added a comment -

          Uploading patch derby-5955-client-restructure-01. This patch restructures the data source hierarchy of the client driver with the same aim as for the embedded driver; to prepare for data sources that are not dependent on JNDI.

          Patch details:

          A ClientDataSourceInterface
          A ClientConnectionPoolDataSourceInterface
          A ClientXADataSourceInterface

          The patch adds three new interfaces allowing the common parts of the data sources to be declared there.

          M java/client/org/apache/derby/jdbc/ClientBaseDataSource.java

          The base implementation, ClientBaseDataSource is analogous to EmbeddedBaseDataSource. It no longer implements Referenceable, that is moved to ClientDataSource. The basic getConnection method is hoisted up into ClientBaseDataSource, as are minion methods for pooled connections and XA connections. Constants are moved to ClientDataSourceInterface. Both the latter changes makes those resources available to new data sources (not yet introduced in this patch) not inheriting ClientDataSource; with its JNDI dependence.

          M java/client/org/apache/derby/client/net/ClientJDBCObjectFactoryImpl.java
          M java/client/org/apache/derby/client/net/ClientJDBCObjectFactoryImpl40.java
          M java/client/org/apache/derby/client/ClientXAConnection.java
          M java/client/org/apache/derby/client/ClientXAConnection40.java
          M java/client/org/apache/derby/client/am/Configuration.java
          M java/client/org/apache/derby/client/am/Connection.java
          M java/client/org/apache/derby/jdbc/ClientDriver.java

          Smaller changes to accomodate the new hierarchy.

          M java/client/org/apache/derby/client/am/LogWriter.java

          Smaller changes to accomodate the new hierarchy plus LogWriter#getAttributes it no longer uses Reference#getAll to get at the data source's attributes, but now uses bean inspection to avoid presuming the data source has implements Referenceable.

          M java/client/org/apache/derby/jdbc/ClientConnectionPoolDataSource.java

          Now uses the minion connection methods and implements the new ClientConnectionPoolDataSourceInterface.

          M java/client/org/apache/derby/jdbc/ClientConnectionPoolDataSource40.java
          M java/client/org/apache/derby/jdbc/ClientDataSource40.java
          M java/client/org/apache/derby/jdbc/ClientXADataSource40.java

          These now implement javax.sql.*DataSource to get compile-time check that they actually implement the 4.1 extensions; added a missing explicit serialVersionUID chosen to be the old default value (otherwise serialization would break with the new hierachy changes).

          M java/client/org/apache/derby/jdbc/ClientDataSource.java

          Now implements Referenceable itself instead of through ClientBaseDataSource.
          Now inherits basic connection methods from ClientBaseDataSource instead of implementing them itself.

          M java/client/org/apache/derby/jdbc/ClientXADataSource.java

          Now implements ClientXADataSourceInterface; hoisted its connection logic up to ClientBaseDataSource.

          M tools/jar/dnc.properties
          M java/client/org/apache/derby/client/am/ClientJDBCObjectFactory.java
          M java/client/org/apache/derby/client/net/NetConnection.java
          M java/client/org/apache/derby/client/net/NetConnection40.java
          M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeTrajectoryTest.java
          M java/testing/org/apache/derbyTesting/junit/J2EEDataSource.java

          Trivial changes

          Running regressions, please review.

          Show
          Dag H. Wanvik added a comment - Uploading patch derby-5955-client-restructure-01. This patch restructures the data source hierarchy of the client driver with the same aim as for the embedded driver; to prepare for data sources that are not dependent on JNDI. Patch details: A ClientDataSourceInterface A ClientConnectionPoolDataSourceInterface A ClientXADataSourceInterface The patch adds three new interfaces allowing the common parts of the data sources to be declared there. M java/client/org/apache/derby/jdbc/ClientBaseDataSource.java The base implementation, ClientBaseDataSource is analogous to EmbeddedBaseDataSource. It no longer implements Referenceable, that is moved to ClientDataSource. The basic getConnection method is hoisted up into ClientBaseDataSource, as are minion methods for pooled connections and XA connections. Constants are moved to ClientDataSourceInterface. Both the latter changes makes those resources available to new data sources (not yet introduced in this patch) not inheriting ClientDataSource; with its JNDI dependence. M java/client/org/apache/derby/client/net/ClientJDBCObjectFactoryImpl.java M java/client/org/apache/derby/client/net/ClientJDBCObjectFactoryImpl40.java M java/client/org/apache/derby/client/ClientXAConnection.java M java/client/org/apache/derby/client/ClientXAConnection40.java M java/client/org/apache/derby/client/am/Configuration.java M java/client/org/apache/derby/client/am/Connection.java M java/client/org/apache/derby/jdbc/ClientDriver.java Smaller changes to accomodate the new hierarchy. M java/client/org/apache/derby/client/am/LogWriter.java Smaller changes to accomodate the new hierarchy plus LogWriter#getAttributes it no longer uses Reference#getAll to get at the data source's attributes, but now uses bean inspection to avoid presuming the data source has implements Referenceable. M java/client/org/apache/derby/jdbc/ClientConnectionPoolDataSource.java Now uses the minion connection methods and implements the new ClientConnectionPoolDataSourceInterface. M java/client/org/apache/derby/jdbc/ClientConnectionPoolDataSource40.java M java/client/org/apache/derby/jdbc/ClientDataSource40.java M java/client/org/apache/derby/jdbc/ClientXADataSource40.java These now implement javax.sql.*DataSource to get compile-time check that they actually implement the 4.1 extensions; added a missing explicit serialVersionUID chosen to be the old default value (otherwise serialization would break with the new hierachy changes). M java/client/org/apache/derby/jdbc/ClientDataSource.java Now implements Referenceable itself instead of through ClientBaseDataSource. Now inherits basic connection methods from ClientBaseDataSource instead of implementing them itself. M java/client/org/apache/derby/jdbc/ClientXADataSource.java Now implements ClientXADataSourceInterface; hoisted its connection logic up to ClientBaseDataSource. M tools/jar/dnc.properties M java/client/org/apache/derby/client/am/ClientJDBCObjectFactory.java M java/client/org/apache/derby/client/net/NetConnection.java M java/client/org/apache/derby/client/net/NetConnection40.java M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeTrajectoryTest.java M java/testing/org/apache/derbyTesting/junit/J2EEDataSource.java Trivial changes Running regressions, please review.
          Hide
          Dag H. Wanvik added a comment -

          Committed follow-up patch derby-5955-embed-restructure-followup: Some white space changes plus a missed fix to EmbeddedDataSource40 which was in the original proof-of-concept patch but fell through the cracks in the committed patch derby-5955-embed-restructure-04.

          Show
          Dag H. Wanvik added a comment - Committed follow-up patch derby-5955-embed-restructure-followup: Some white space changes plus a missed fix to EmbeddedDataSource40 which was in the original proof-of-concept patch but fell through the cracks in the committed patch derby-5955-embed-restructure-04.
          Hide
          Dag H. Wanvik added a comment -

          Committed "*-embed-restructure-04" as svn 1427045.

          Show
          Dag H. Wanvik added a comment - Committed "*-embed-restructure-04" as svn 1427045.
          Hide
          Dag H. Wanvik added a comment -

          Uploading patch "*-embed-restructure-04"; relative to version 03 it removes the changes to EmbedSimpleDataSource. [Those changes were part of an earlier effort to upgrade ESDS to be the vehicle for JEP 161 - I since changed course and restructured the main data sources to make the JEP 161 offering more functionally capable.]

          Show
          Dag H. Wanvik added a comment - Uploading patch "*-embed-restructure-04"; relative to version 03 it removes the changes to EmbedSimpleDataSource. [Those changes were part of an earlier effort to upgrade ESDS to be the vehicle for JEP 161 - I since changed course and restructured the main data sources to make the JEP 161 offering more functionally capable.]
          Hide
          Dag H. Wanvik added a comment -

          Uploading patch *-embed-restructure-03, addressing Knut's comments. Will commit after regressions.

          Show
          Dag H. Wanvik added a comment - Uploading patch *-embed-restructure-03, addressing Knut's comments. Will commit after regressions.
          Hide
          Dag H. Wanvik added a comment -

          Thanks, Knut and Rick for the reviews. I'll spin a reworked version and commit that.

          Show
          Dag H. Wanvik added a comment - Thanks, Knut and Rick for the reviews. I'll spin a reworked version and commit that.
          Hide
          Rick Hillegas added a comment -

          The revised published api looks good to me. Thanks.

          Show
          Rick Hillegas added a comment - The revised published api looks good to me. Thanks.
          Hide
          Knut Anders Hatlen added a comment -

          The version 2 patch seems to preserve the original functionality and interfaces, as far as I can tell, and I think the new hierarchy is better structured, so it looks like a net improvement to me.

          There seems to be one added piece of functionality in the patch: EmbeddedSimpleDataSource now implements the setAttributesAsPassword() method supported by the other embedded data sources. But that looks like an improvement too.

          Some minor comments:

          • There's some odd formatting. Most of it because already poorly formatted code was moved (like the equals() method moved from EmbeddedDataSource to EmbeddedBaseDataSource). And in EmbeddedDataSourceInterface the indentation alternates between 3 and 4. I see you've already removed tabs from the copied/moved code. Maybe you can take it one step further and tell your favourite IDE to reformat the entire EmbeddedBaseDataSource and EmbeddedDataSourceInterface files? Since those are new files, reformatting them won't make archeology any harder.
          • A static field STRING_ARG is added to EmbeddedDataSource, but it's never used.
          • Some code is added to the JDBCDataSource test in order to preserve stack trace and exception chain in case of failure. Would a call to BaseTestCase.fail(String,Throwable) do the same trick?
          Show
          Knut Anders Hatlen added a comment - The version 2 patch seems to preserve the original functionality and interfaces, as far as I can tell, and I think the new hierarchy is better structured, so it looks like a net improvement to me. There seems to be one added piece of functionality in the patch: EmbeddedSimpleDataSource now implements the setAttributesAsPassword() method supported by the other embedded data sources. But that looks like an improvement too. Some minor comments: There's some odd formatting. Most of it because already poorly formatted code was moved (like the equals() method moved from EmbeddedDataSource to EmbeddedBaseDataSource). And in EmbeddedDataSourceInterface the indentation alternates between 3 and 4. I see you've already removed tabs from the copied/moved code. Maybe you can take it one step further and tell your favourite IDE to reformat the entire EmbeddedBaseDataSource and EmbeddedDataSourceInterface files? Since those are new files, reformatting them won't make archeology any harder. A static field STRING_ARG is added to EmbeddedDataSource, but it's never used. Some code is added to the JDBCDataSource test in order to preserve stack trace and exception chain in case of failure. Would a call to BaseTestCase.fail(String,Throwable) do the same trick?
          Hide
          Dag H. Wanvik added a comment -

          Uploading version 2 of the "derby-5955-embed-restructure" patch to correct a Javadoc issue (prematurely referencing the NonJNDI data sources); that will follow later.

          Show
          Dag H. Wanvik added a comment - Uploading version 2 of the "derby-5955-embed-restructure" patch to correct a Javadoc issue (prematurely referencing the NonJNDI data sources); that will follow later.
          Hide
          Dag H. Wanvik added a comment -

          Regressions ran cleanly.

          Show
          Dag H. Wanvik added a comment - Regressions ran cleanly.
          Hide
          Dag H. Wanvik added a comment -

          Attaching derby-5955-embed-restructure-01, a cleaned up part of the p-o-c patch, for review with a view to commit it.

          Running regressions on Java SE (the regressions on JEP 161 Java 8 will wait till I'm done with committing most or all all installments).

          This patch adds no new functionality, just refactors the embedded data sources to get the hierarchy ready for the non-jndi extensions (for the embedded driver).

          Show
          Dag H. Wanvik added a comment - Attaching derby-5955-embed-restructure-01, a cleaned up part of the p-o-c patch, for review with a view to commit it. Running regressions on Java SE (the regressions on JEP 161 Java 8 will wait till I'm done with committing most or all all installments). This patch adds no new functionality, just refactors the embedded data sources to get the hierarchy ready for the non-jndi extensions (for the embedded driver).
          Hide
          Dag H. Wanvik added a comment -

          Note: on the point of putting ReferenceableDataSource back where above EmbeddedDataSource: this is only a ds factory for embedded, the client uses its own: ClientDataSourceFactory which is not part of the ds inheritance hierarchy (sensibly IMHO).

          Show
          Dag H. Wanvik added a comment - Note: on the point of putting ReferenceableDataSource back where above EmbeddedDataSource: this is only a ds factory for embedded, the client uses its own: ClientDataSourceFactory which is not part of the ds inheritance hierarchy (sensibly IMHO).
          Hide
          Dag H. Wanvik added a comment -

          Uploading a generated html-overview of the API diff changes in the org.apache.derby.jdbc package. It should make it easy to see what has changed. Just unzip and point your browser to the resulting directory.

          Show
          Dag H. Wanvik added a comment - Uploading a generated html-overview of the API diff changes in the org.apache.derby.jdbc package. It should make it easy to see what has changed. Just unzip and point your browser to the resulting directory.
          Hide
          Dag H. Wanvik added a comment -

          Uploaded a revised version including new javadocs incorporating the suggestions from Knut and Rick.

          It was indeed possible re re-inject ReferenceableDataSource between the two EmbeddedBaseDataSource and EmbeddedDataSource, I just had to explicitly specify the correct SerialVersionUID for it (it used the default which now changes due to an additional ancestor).

          The interfaces have been renamed (no abbrev) and removed for the API.

          Rerunning regressions on both SE and JEP 161 platforms.

          If this looks generally like an OK approach, I'll start making and committing smaller patches as per the plan I outlined above.

          Show
          Dag H. Wanvik added a comment - Uploaded a revised version including new javadocs incorporating the suggestions from Knut and Rick. It was indeed possible re re-inject ReferenceableDataSource between the two EmbeddedBaseDataSource and EmbeddedDataSource, I just had to explicitly specify the correct SerialVersionUID for it (it used the default which now changes due to an additional ancestor). The interfaces have been renamed (no abbrev) and removed for the API. Rerunning regressions on both SE and JEP 161 platforms. If this looks generally like an OK approach, I'll start making and committing smaller patches as per the plan I outlined above.
          Hide
          Rick Hillegas added a comment -

          Thanks for the responses, Dag and Knut. Some further thoughts:

          (1) & (2): I agree with what Knut says.

          (3) & (4): What Knut says should work. Maybe all you may have to do is move ReferenceableDataSource.getObjectInstance() into EmbeddedDataSource, and move ReferenceableDataSource.getReference() into ClientDataSource.

          Thanks,
          -Rick

          Show
          Rick Hillegas added a comment - Thanks for the responses, Dag and Knut. Some further thoughts: (1) & (2): I agree with what Knut says. (3) & (4): What Knut says should work. Maybe all you may have to do is move ReferenceableDataSource.getObjectInstance() into EmbeddedDataSource, and move ReferenceableDataSource.getReference() into ClientDataSource. Thanks, -Rick
          Hide
          Knut Anders Hatlen added a comment -

          Sounds like the interfaces are useful enough for making our internals cleaner, so we could keep them, but leave them out of the published API. It's easier to add the interfaces to the published API later if we find that they are useful to applications, than it is to remove them. So the safe option is to wait and not add them to the published API just yet. Same reasoning could be used about EmbeddedBaseDataSource.

          I'd prefer the DSI part of the interface names to be spelled out, though, as the "I" in the abbreviation could just as well stand for "Implementation".

          As to ReferenceableDataSource and ObjectFactory, if we're worried that the existing full DataSources no longer implement them, couldn't we reinsert that class between EmbeddedBaseDataSource and EmbeddedDataSource in the inheritance graph? It looks as if that would preserve the original shape of the full DataSource implementations and not introduce any JNDI dependencies in the non-JNDI variants.

          Show
          Knut Anders Hatlen added a comment - Sounds like the interfaces are useful enough for making our internals cleaner, so we could keep them, but leave them out of the published API. It's easier to add the interfaces to the published API later if we find that they are useful to applications, than it is to remove them. So the safe option is to wait and not add them to the published API just yet. Same reasoning could be used about EmbeddedBaseDataSource. I'd prefer the DSI part of the interface names to be spelled out, though, as the "I" in the abbreviation could just as well stand for "Implementation". As to ReferenceableDataSource and ObjectFactory, if we're worried that the existing full DataSources no longer implement them, couldn't we reinsert that class between EmbeddedBaseDataSource and EmbeddedDataSource in the inheritance graph? It looks as if that would preserve the original shape of the full DataSource implementations and not introduce any JNDI dependencies in the non-JNDI variants.
          Hide
          Dag H. Wanvik added a comment - - edited

          Thanks, Rick. Here are some comments, in-lined between your points.

          > 1) There are no interfaces in the 10.9 public api for the jdbc package. I see that you are introducing several interfaces in that package. Do those interfaces need to be part of the public API?

          Probably not. I use them on an application level in the tests to avoid having the code have to decide at compile-time whether it will run with JNDI or not, cf my use of Class.forName there to create the data sources. The interface allows type-safe calls to the setters and getters, which would otherwise need to be called via reflection. But for user code this flexibility may not be strictly needed, what do you think? It may not carry its weight... See e.g. this section of the test J2EEDataSourceTest#testClientDSConnectionAttributes:

          // now with ConnectionPoolDataSource
          ClientConnectionPoolDSI cpds;

          if (JDBC.vmSupportsNonJNDI())

          { cpds = (ClientConnectionPoolDSI)Class.forName("org.apache.derby.jdbc.NonJNDIClientConnectionPoolDataSource40").newInstance(); }

          else

          { cpds = (ClientConnectionPoolDSI)Class.forName("org.apache.derby.jdbc.ClientConnectionPoolDataSource").newInstance(); }

          cpds.setPortNumber(TestConfiguration.getCurrent().getPort());

          >
          > 2) Similar question: You have introduced a new EmbeddedBaseDataSource class. Does this class need to be part of the public api?

          No, I don't think it needs to be. ReferenceableDataSource wasn't part of the API either (which currently implement the getters and setters, e.g. setUser/getUser).

          But note that ClientBaseDataSource is part of the public API, so I included EmbeddedBaseDataSource by analogy. Comment?

          >
          > 3) EmbeddedConnectionPoolDataSource, EmbeddedDataSource, EmbeddedXADataSource, EmbeddedConnectionPoolDataSource40, EmbeddedDataSource40, and EmbeddedXADataSource40 no longer implement ObjectFactory. That is a change to the public api which should be easy to fix.

          Yes, but ReferenceableDataSource still implements it. It's just not inherited by the DSes anymore.
          And the JNDI-full DSes still implement Referenceable. Isn't that sufficient? Not quite sure what you mean by "should be easy to fix"...

          >
          > 4) The inheritance hierarchy has been changed for several classes. The changes involve removing classes which were NOT part of the public api and inserting new classes which probably don't need to be part of the public api. These changes could affect code which crawls up the hierarchy via, for instance, calls to super(). In order for this to affect applications, however, they would have to crawl up the hierarchy through classes which are not part of the public api. I do not think it is likely that anyone does this. And if they do, I think your warranty is violated when you crawl into classes which are not part of the public api. This issue is probably worth a release note but I don't think that it is a significant change to the public api.

          OK, agreed.

          >
          > 5) ClientBaseDataSource no longer implements javax.naming.Referenceable. In my opinion, this is the most serious change to the public api. This is an abstract class, so no one can directly instantiate one of these things. However, someone writing a test framework might use this abstraction in order to factor out tests which should be run against different Derby DataSources. Such a framework might be interested in the fact that ClientBaseDataSource implements Referenceable.

          OK. Any suggestions?

          Show
          Dag H. Wanvik added a comment - - edited Thanks, Rick. Here are some comments, in-lined between your points. > 1) There are no interfaces in the 10.9 public api for the jdbc package. I see that you are introducing several interfaces in that package. Do those interfaces need to be part of the public API? Probably not. I use them on an application level in the tests to avoid having the code have to decide at compile-time whether it will run with JNDI or not, cf my use of Class.forName there to create the data sources. The interface allows type-safe calls to the setters and getters, which would otherwise need to be called via reflection. But for user code this flexibility may not be strictly needed, what do you think? It may not carry its weight... See e.g. this section of the test J2EEDataSourceTest#testClientDSConnectionAttributes: // now with ConnectionPoolDataSource ClientConnectionPoolDSI cpds; if (JDBC.vmSupportsNonJNDI()) { cpds = (ClientConnectionPoolDSI)Class.forName("org.apache.derby.jdbc.NonJNDIClientConnectionPoolDataSource40").newInstance(); } else { cpds = (ClientConnectionPoolDSI)Class.forName("org.apache.derby.jdbc.ClientConnectionPoolDataSource").newInstance(); } cpds.setPortNumber(TestConfiguration.getCurrent().getPort()); > > 2) Similar question: You have introduced a new EmbeddedBaseDataSource class. Does this class need to be part of the public api? No, I don't think it needs to be. ReferenceableDataSource wasn't part of the API either (which currently implement the getters and setters, e.g. setUser/getUser). But note that ClientBaseDataSource is part of the public API, so I included EmbeddedBaseDataSource by analogy. Comment? > > 3) EmbeddedConnectionPoolDataSource, EmbeddedDataSource, EmbeddedXADataSource, EmbeddedConnectionPoolDataSource40, EmbeddedDataSource40, and EmbeddedXADataSource40 no longer implement ObjectFactory. That is a change to the public api which should be easy to fix. Yes, but ReferenceableDataSource still implements it. It's just not inherited by the DSes anymore. And the JNDI-full DSes still implement Referenceable. Isn't that sufficient? Not quite sure what you mean by "should be easy to fix"... > > 4) The inheritance hierarchy has been changed for several classes. The changes involve removing classes which were NOT part of the public api and inserting new classes which probably don't need to be part of the public api. These changes could affect code which crawls up the hierarchy via, for instance, calls to super(). In order for this to affect applications, however, they would have to crawl up the hierarchy through classes which are not part of the public api. I do not think it is likely that anyone does this. And if they do, I think your warranty is violated when you crawl into classes which are not part of the public api. This issue is probably worth a release note but I don't think that it is a significant change to the public api. OK, agreed. > > 5) ClientBaseDataSource no longer implements javax.naming.Referenceable. In my opinion, this is the most serious change to the public api. This is an abstract class, so no one can directly instantiate one of these things. However, someone writing a test framework might use this abstraction in order to factor out tests which should be run against different Derby DataSources. Such a framework might be interested in the fact that ClientBaseDataSource implements Referenceable. OK. Any suggestions?
          Hide
          Rick Hillegas added a comment -

          Hi Dag,

          Here are some further thoughts about the new public api introduced by this patch:

          1) There are no interfaces in the 10.9 public api for the jdbc package. I see that you are introducing several interfaces in that package. Do those interfaces need to be part of the public api?

          2) Similar question: You have introduced a new EmbeddedBaseDataSource class. Does this class need to be part of the public api?

          3) EmbeddedConnectionPoolDataSource, EmbeddedDataSource, EmbeddedXADataSource, EmbeddedConnectionPoolDataSource40, EmbeddedDataSource40, and EmbeddedXADataSource40 no longer implement ObjectFactory. That is a change to the public api which should be easy to fix.

          4) The inheritance hierarchy has been changed for several classes. The changes involve removing classes which were NOT part of the public api and inserting new classes which probably don't need to be part of the public api. These changes could affect code which crawls up the hierarchy via, for instance, calls to super(). In order for this to affect applications, however, they would have to crawl up the hierarchy through classes which are not part of the public api. I do not think it is likely that anyone does this. And if they do, I think your warranty is violated when you crawl into classes which are not part of the public api. This issue is probably worth a release note but I don't think that it is a significant change to the public api.

          5) ClientBaseDataSource no longer implements javax.naming.Referenceable. In my opinion, this is the most serious change to the public api. This is an abstract class, so no one can directly instantiate one of these things. However, someone writing a test framework might use this abstraction in order to factor out tests which should be run against different Derby DataSources. Such a framework might be interested in the fact that ClientBaseDataSource implements Referenceable.

          Thanks,
          -Rick

          Here is a more detailed analysis of the changes to the public javadoc introduced by this patch:

          ------ JDBC 3.0 DataSources --------------

          ClientBaseDataSource

          • No longer implements javax.naming.Referenceable. This is the most serious change to Derby's public api.
          • Now implements some additional interfaces.

          ClientConnectionPoolDataSource

          • Now implements some new interfaces.

          ClientDataSource

          • Now implements some new interfaces.

          ClientXADataSource

          • Now implements some new interfaces.

          EmbeddedConnectionPoolDataSource

          • No longer descends from ReferenceableDataSource. But that class is not part of the public api so this is not a serious change to the public api.
          • No longer implements ObjectFactory. That is an easily fixed change to the public api.
          • Now implements some new interfaces.

          EmbeddedDataSource

          • No longer descends from ReferenceableDataSource. But that class is not part of the public api so this is not a serious change to the public api.
          • Now descends from new class EmbeddedBaseDataSource.
          • No longer implements ObjectFactory. That is an easily fixed change to the public api.
          • Now implements some new interfaces.

          EmbeddedSimpleDataSource

          • No changes.

          EmbeddedXADataSource

          • No longer descends from ReferenceableDataSource. But that class is not part of the public api so this is not a serious change to the public api.
          • Now descends from new class EmbeddedBaseDataSource.
          • No longer implements ObjectFactory. That is an easily fixed change to the public api.
          • Now implements some new interfaces.

          ------ JDBC 4.0 DataSources --------------

          ClientConnectionPoolDataSource40

          • Now implements some new interfaces.

          ClientDataSource40

          • Now implements some new interfaces.

          ClientXADataSource40

          • Now implements some new interfaces.

          EmbeddedConnectionPoolDataSource40

          • No longer descends from ReferenceableDataSource. But that class is not part of the public api so this is not a serious change to the public api.
          • Now descends from new class EmbeddedBaseDataSource.
          • No longer implements ObjectFactory. That is an easily fixed change to the public api.
          • Now implements some new interfaces.

          EmbeddedDataSource40

          • No longer descends from ReferenceableDataSource. But that class is not part of the public api so this is not a serious change to the public api.
          • Now descends from new class EmbeddedBaseDataSource.
          • No longer implements ObjectFactory. That is an easily fixed change to the public api.
          • Now implements some new interfaces.

          EmbeddedXADataSource40

          • No longer descends from ReferenceableDataSource. But that class is not part of the public api so this is not a serious change to the public api.
          • Now descends from new class EmbeddedBaseDataSource.
          • No longer implements ObjectFactory. That is an easily fixed change to the public api.
          • Now implements some new interfaces.
          Show
          Rick Hillegas added a comment - Hi Dag, Here are some further thoughts about the new public api introduced by this patch: 1) There are no interfaces in the 10.9 public api for the jdbc package. I see that you are introducing several interfaces in that package. Do those interfaces need to be part of the public api? 2) Similar question: You have introduced a new EmbeddedBaseDataSource class. Does this class need to be part of the public api? 3) EmbeddedConnectionPoolDataSource, EmbeddedDataSource, EmbeddedXADataSource, EmbeddedConnectionPoolDataSource40, EmbeddedDataSource40, and EmbeddedXADataSource40 no longer implement ObjectFactory. That is a change to the public api which should be easy to fix. 4) The inheritance hierarchy has been changed for several classes. The changes involve removing classes which were NOT part of the public api and inserting new classes which probably don't need to be part of the public api. These changes could affect code which crawls up the hierarchy via, for instance, calls to super(). In order for this to affect applications, however, they would have to crawl up the hierarchy through classes which are not part of the public api. I do not think it is likely that anyone does this. And if they do, I think your warranty is violated when you crawl into classes which are not part of the public api. This issue is probably worth a release note but I don't think that it is a significant change to the public api. 5) ClientBaseDataSource no longer implements javax.naming.Referenceable. In my opinion, this is the most serious change to the public api. This is an abstract class, so no one can directly instantiate one of these things. However, someone writing a test framework might use this abstraction in order to factor out tests which should be run against different Derby DataSources. Such a framework might be interested in the fact that ClientBaseDataSource implements Referenceable. Thanks, -Rick Here is a more detailed analysis of the changes to the public javadoc introduced by this patch: ------ JDBC 3.0 DataSources -------------- ClientBaseDataSource No longer implements javax.naming.Referenceable. This is the most serious change to Derby's public api. Now implements some additional interfaces. ClientConnectionPoolDataSource Now implements some new interfaces. ClientDataSource Now implements some new interfaces. ClientXADataSource Now implements some new interfaces. EmbeddedConnectionPoolDataSource No longer descends from ReferenceableDataSource. But that class is not part of the public api so this is not a serious change to the public api. No longer implements ObjectFactory. That is an easily fixed change to the public api. Now implements some new interfaces. EmbeddedDataSource No longer descends from ReferenceableDataSource. But that class is not part of the public api so this is not a serious change to the public api. Now descends from new class EmbeddedBaseDataSource. No longer implements ObjectFactory. That is an easily fixed change to the public api. Now implements some new interfaces. EmbeddedSimpleDataSource No changes. EmbeddedXADataSource No longer descends from ReferenceableDataSource. But that class is not part of the public api so this is not a serious change to the public api. Now descends from new class EmbeddedBaseDataSource. No longer implements ObjectFactory. That is an easily fixed change to the public api. Now implements some new interfaces. ------ JDBC 4.0 DataSources -------------- ClientConnectionPoolDataSource40 Now implements some new interfaces. ClientDataSource40 Now implements some new interfaces. ClientXADataSource40 Now implements some new interfaces. EmbeddedConnectionPoolDataSource40 No longer descends from ReferenceableDataSource. But that class is not part of the public api so this is not a serious change to the public api. Now descends from new class EmbeddedBaseDataSource. No longer implements ObjectFactory. That is an easily fixed change to the public api. Now implements some new interfaces. EmbeddedDataSource40 No longer descends from ReferenceableDataSource. But that class is not part of the public api so this is not a serious change to the public api. Now descends from new class EmbeddedBaseDataSource. No longer implements ObjectFactory. That is an easily fixed change to the public api. Now implements some new interfaces. EmbeddedXADataSource40 No longer descends from ReferenceableDataSource. But that class is not part of the public api so this is not a serious change to the public api. Now descends from new class EmbeddedBaseDataSource. No longer implements ObjectFactory. That is an easily fixed change to the public api. Now implements some new interfaces.
          Hide
          Rick Hillegas added a comment -

          Thanks, Dag. The javadoc is very helpful. This is my understanding of how an application would use these DataSources:

          1) If the application wants to run with JNDI, then the application would use the same DataSources which are used in 10.9.

          2) If the application wants to run on the small CP2 profile, then the application would use the corresponding NonJNDI* DataSources instead.

          It would probably be useful to touch up the header javadoc for all of the DataSources in order to make it clear which environment they should be used in. Thanks!

          Show
          Rick Hillegas added a comment - Thanks, Dag. The javadoc is very helpful. This is my understanding of how an application would use these DataSources: 1) If the application wants to run with JNDI, then the application would use the same DataSources which are used in 10.9. 2) If the application wants to run on the small CP2 profile, then the application would use the corresponding NonJNDI* DataSources instead. It would probably be useful to touch up the header javadoc for all of the DataSources in order to make it clear which environment they should be used in. Thanks!
          Hide
          Dag H. Wanvik added a comment -

          Thanks, Rick! uploading the API javadocs.

          Show
          Dag H. Wanvik added a comment - Thanks, Rick! uploading the API javadocs.
          Hide
          Rick Hillegas added a comment -

          Thanks, Dag. This looks very promising. The graphs are very helpful. It would also be useful to see what the public api javadoc would look like with this solution. Could you generate that javadoc? It would be a useful starting point for a discussion about how these classes would be used by a CP2-limited application vs. a CP3-requiring application. Thanks!

          Show
          Rick Hillegas added a comment - Thanks, Dag. This looks very promising. The graphs are very helpful. It would also be useful to see what the public api javadoc would look like with this solution. Could you generate that javadoc? It would be a useful starting point for a discussion about how these classes would be used by a CP2-limited application vs. a CP3-requiring application. Thanks!
          Hide
          Dag H. Wanvik added a comment -

          Note that while ReferenceableDataSource is no longer a base class of the embedded data sources (in the new embedded diagram), it still exists as a factory class whose purpose it is to reconstruct a Derby embedded-driver data source object from a JNDI data source reference.

          Show
          Dag H. Wanvik added a comment - Note that while ReferenceableDataSource is no longer a base class of the embedded data sources (in the new embedded diagram), it still exists as a factory class whose purpose it is to reconstruct a Derby embedded-driver data source object from a JNDI data source reference.
          Hide
          Dag H. Wanvik added a comment -

          Uploaded the ds class graphs without the patch: "old-*.png".

          Show
          Dag H. Wanvik added a comment - Uploaded the ds class graphs without the patch: "old-*.png".
          Hide
          Dag H. Wanvik added a comment -

          Good idea, Mamta! I'll make diagrams for the old ones and upload them. As for tool, I used a hack: a combination of my own parser to extract Java implements/extends info from the all the Derby classes, then Emacs Lisp to select a subset of those dependencies using a regular expression on the class name and convert the data into the ".dot" source file format of Graphviz (http://www.graphviz.org), which generated the diagrams.

          Show
          Dag H. Wanvik added a comment - Good idea, Mamta! I'll make diagrams for the old ones and upload them. As for tool, I used a hack: a combination of my own parser to extract Java implements/extends info from the all the Derby classes, then Emacs Lisp to select a subset of those dependencies using a regular expression on the class name and convert the data into the ".dot" source file format of Graphviz ( http://www.graphviz.org ), which generated the diagrams.
          Hide
          Mamta A. Satoor added a comment -

          Hi Dag, thanks for taking on this big task. If possible, it will be helpful if you can provided a class diagram for embedded and client data sources as they exist in trunk today. It will make it easier to see the changes .Also, I was wondering what tool did you use to create the class diagram? Thanks

          Show
          Mamta A. Satoor added a comment - Hi Dag, thanks for taking on this big task. If possible, it will be helpful if you can provided a class diagram for embedded and client data sources as they exist in trunk today. It will make it easier to see the changes .Also, I was wondering what tool did you use to create the class diagram? Thanks
          Hide
          Dag H. Wanvik added a comment - - edited

          Uploading an experimental "monster" proof-of-concept patch. The main thrust is as follows:

          Refactor the data source heierachies for client and embedded to allow variants that do no require JNDI. These data source have class names starting with "NonJNDI" followed by the usual data source class names, e.g. "NonJNDIClientXADataSource40". I used the "40" suffix to classify the class on a par with other JDBC 4.1 classes, there is no "NonJNDIClientXADataSource". Please also see the attached class diagrams (*.png).

          To avoid redundant code for the client, I have hoisted more code up into data source base class ClientBaseDataSource. For embedded, I have introduced a similar "EmbeddedBaseDataSource" to allow the old data source classes and the new non-JNDI classes to share implementation code.

          I have introduced interfaces corresponding to plain, XA and connection pooling data sources to allow the tests and user code, and also implementation code in places to avoid excessive casting, e.g. "ClientDSI", "ClientConnectionPoolDSI" etc.

          The patch also revamps the data source serialization tests, which haven't been update since release 10.3 by adding 10_10*.ser data files. Btw, these do not follow the usual "generate from source", see DERBY-5997. Until such time as that is fixed, this patch requires the binary bundle I attach ("derby-5955-ser.zip"; unzip in the directory java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/) to this issue to run the regressions correctly.

          Much of the other changes are in implementation to avoid using the "JNDI-full" classes verbatim in the code without reflection, as this breaks on a Non-JNDI platform.

          Furthermore, the engine, drivers and tests have been modified to detect the absence of JNDI and do the right thing.

          ij also had data source dependencies so some changes there, as well as changes to generate Javadoc for the new classes.

          With the present changes, all regressions ran ok on Java SE 5 and 7, as well as with my build of the JEP 161 Java 8 repository [1]. The latter exercises the new "non-JNDI" code.

          Going forward, I'd like to produces smaller patches for review and commit, all the while while keeping the standard SE regression tests running without error. The regressions under JEP 161 Java 8 will only work fully when all the pieces have been committed, though. Does this sound like an acceptable plan?

          At this point I'd like feed-back on my general approach.

          Thanks.

          [1] http://hg.openjdk.java.net/jdk8/profiles

          Show
          Dag H. Wanvik added a comment - - edited Uploading an experimental "monster" proof-of-concept patch. The main thrust is as follows: Refactor the data source heierachies for client and embedded to allow variants that do no require JNDI. These data source have class names starting with "NonJNDI" followed by the usual data source class names, e.g. "NonJNDIClientXADataSource40". I used the "40" suffix to classify the class on a par with other JDBC 4.1 classes, there is no "NonJNDIClientXADataSource". Please also see the attached class diagrams (*.png). To avoid redundant code for the client, I have hoisted more code up into data source base class ClientBaseDataSource. For embedded, I have introduced a similar "EmbeddedBaseDataSource" to allow the old data source classes and the new non-JNDI classes to share implementation code. I have introduced interfaces corresponding to plain, XA and connection pooling data sources to allow the tests and user code, and also implementation code in places to avoid excessive casting, e.g. "ClientDSI", "ClientConnectionPoolDSI" etc. The patch also revamps the data source serialization tests, which haven't been update since release 10.3 by adding 10_10*.ser data files. Btw, these do not follow the usual "generate from source", see DERBY-5997 . Until such time as that is fixed, this patch requires the binary bundle I attach ("derby-5955-ser.zip"; unzip in the directory java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/) to this issue to run the regressions correctly. Much of the other changes are in implementation to avoid using the "JNDI-full" classes verbatim in the code without reflection, as this breaks on a Non-JNDI platform. Furthermore, the engine, drivers and tests have been modified to detect the absence of JNDI and do the right thing. ij also had data source dependencies so some changes there, as well as changes to generate Javadoc for the new classes. With the present changes, all regressions ran ok on Java SE 5 and 7, as well as with my build of the JEP 161 Java 8 repository [1] . The latter exercises the new "non-JNDI" code. Going forward, I'd like to produces smaller patches for review and commit, all the while while keeping the standard SE regression tests running without error. The regressions under JEP 161 Java 8 will only work fully when all the pieces have been committed, though. Does this sound like an acceptable plan? At this point I'd like feed-back on my general approach. Thanks. [1] http://hg.openjdk.java.net/jdk8/profiles
          Hide
          Dag H. Wanvik added a comment -

          I have run an initial set of tests using Java 8 with CP2. This profile has java.sql and javax.sql, except javax.sql.rowset.
          The first issue I see is that the Derby data sources are implemented with JNDI, which is not included in CP2.
          The EmbeddedSimpleDataSource which was constructed for CD can be used for embedded. Both the XA and connection pooling
          interfaces are in java.sqlx, so it would be nice if we could provide Non JNDI dependent implementations of those too. I'll have a look to see how hard it would be to factor out JNDI and use it only if it is available (with a JRE >= CP3).

          Show
          Dag H. Wanvik added a comment - I have run an initial set of tests using Java 8 with CP2. This profile has java.sql and javax.sql, except javax.sql.rowset. The first issue I see is that the Derby data sources are implemented with JNDI, which is not included in CP2. The EmbeddedSimpleDataSource which was constructed for CD can be used for embedded. Both the XA and connection pooling interfaces are in java.sqlx, so it would be nice if we could provide Non JNDI dependent implementations of those too. I'll have a look to see how hard it would be to factor out JNDI and use it only if it is available (with a JRE >= CP3).

            People

            • Assignee:
              Dag H. Wanvik
              Reporter:
              Dag H. Wanvik
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development