db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DERBY-5955) Prepare Derby to run with Compact Profiles (JEP 161)
Date Wed, 28 Nov 2012 14:48:58 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505497#comment-13505497
] 

Dag H. Wanvik edited comment on DERBY-5955 at 11/28/12 2:48 PM:
----------------------------------------------------------------

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

                
      was (Author: dagw):
    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. 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.

                  
> 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: client-graph.png, derby-5955-proof-of-concept.diff, derby-5955-proof-of-concept.stat,
derby-5955-ser.zip, embedded-graph.png
>
>
> 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

Mime
View raw message