[
https://issues.apache.org/jira/browse/DERBY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-5955:
---------------------------------
Attachment: derby-5955-make-tests-run-02.stat
derby-5955-make-tests-run-02.diff
Thanks, Knut and Rick!
Uploading a new patch revision; derby-5955-make-tests-run-02. I ran this on
Java 1.5 to check any issues with Java 3/4 in the modified tests, I had to make
one change to accommodate for that (DataSourceSerializationTest#deSerializeDs).
I also refreshed the JEP-161 source repo and buildt with the latest sources of
Java 8 CP2 and ran the the regression tests without errors.
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.
> Prepare Derby to run with Compact Profiles (JEP 161)
> ----------------------------------------------------
>
> Key: DERBY-5955
> URL: https://issues.apache.org/jira/browse/DERBY-5955
> Project: Derby
> Issue Type: Improvement
> Components: Documentation, JDBC, Services, SQL
> Reporter: Dag H. Wanvik
> Assignee: Dag H. Wanvik
> Attachments: apidiff.zip, client-graph.png,
> derby-5955-add-cp2-to-jars.diff, derby-5955-client-restructure-01.diff,
> derby-5955-client-restructure-01.stat,
> derby-5955-client-restructure-02-delta.diff,
> derby-5955-client-restructure-02.diff, derby-5955-client-restructure-02.stat,
> derby-5955-embed-restructure-01.diff, derby-5955-embed-restructure-01.stat,
> derby-5955-embed-restructure-02.diff, derby-5955-embed-restructure-02.stat,
> derby-5955-embed-restructure-03.diff, derby-5955-embed-restructure-03.stat,
> derby-5955-embed-restructure-04.diff, derby-5955-embed-restructure-04.stat,
> derby-5955-embed-restructure-followup.diff,
> derby-5955-embed-restructure-followup.stat,
> derby-5955-make-tests-run-01.diff, derby-5955-make-tests-run-01.stat,
> derby-5955-make-tests-run-02.diff, derby-5955-make-tests-run-02.stat,
> derby-5955-new-non-jndi-ds-01.diff, derby-5955-new-non-jndi-ds-01.stat,
> derby-5955-new-non-jndi-ds-02.diff, derby-5955-new-non-jndi-ds-02.stat,
> derby-5955-proof-of-concept-2.diff, derby-5955-proof-of-concept-2.stat,
> derby-5955-proof-of-concept.diff, derby-5955-proof-of-concept.stat,
> derby-5955-ser-b.zip, derby-5955-ser.zip, embedded-graph.png,
> old-client-graph.png, old-embedded-graph.png, publishedapi.zip,
> publishedapi.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
