db-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <rwaldh...@apache.org>
Subject [VOTE][PROPOSAL] db-commons-jdbp
Date Thu, 17 Apr 2003 23:27:00 GMT
It's a small start, but at it's a start.   Here's a proposal for a
db-commons component.  You can find an HTML version of this proposal at

Please vote:

  I vote as follows on approving JDBP as a DB Commons component:

  [ ] +1 - I support this proposal
  [ ] +0 - I support this proposal, but cannot assist
  [ ] -0 - I don't support this proposal
  [ ] -1 - I vote against this proposal for the following reason:

Note that this is a majority vote, requiring 3 binding +1s and more
binding +1s than binding -1s to pass.


(0) rationale

Specializing objects via composition rather than inheritance is a common
idiom. This approach is especially useful when one would like to add
runtime, "mix-in" behaviors to arbitrary implementations of some

Java's JDBC API is a good example of this scenario.  The JDBC
specification defines an interface that is implemented by many vendors.  A
component that seeks to add functionality to an arbitrary JDBC
implementation should not expect compile-time access to or modification of
the underlying types.  At the same time, there are a number of interesting
behaviors may be layered on top of JDBC, including connection and
statement pooling, data caching, logging and profiling, translation from
one vendor's syntax to another, etc.  Many of these can be implemented by
"wrapping" an arbitrary instance of some JDBC type.  For instance, one may
log SQL statements by adding a logging call to the various
Statement.execute methods. Similarly, transparent connection pooling can
be added to an arbitrary JDBC implementation by hooking in to the
getConnection and close methods while passing the remaining method calls
straight through to the underlying implementation.

Unfortunately, JDBC is also a very large API.  java.sql.ResultSet alone
defines over 100 methods. Developers that want to create a ResultSet
wrapper that delegates most calls to the underlying instance are left with
the tedious implementation of dozens methods of the form "public Foo
getFoo() { return delegate.getFoo(); }".  The availability of a common
JDBC proxy implementation and related utilities under an Apache license
would remove much this tedium and may encourage the development of
composable JDBC extensions.

(1) scope of the component

JDBP will provide "proxy" implementations of the JDBC types, delegating
most or all method calls to some underlying instance of the type. As pure
proxy implementations, JDBP will be of little utility in and of itself.
It is intended to support other components who seek to specialize the
behavior of an arbitrary JDBC implementation by providing "mix-in"
behaviors via composition.

(1.1) interaction with other components

JDBP will depend upon Java's JDBC packages (java.sql, javax.sql, etc.),
but likely little else.

It is expected but not required that other components will make use of the
JDBP component.

(2) identify the initial source for the component

The initial codebase will be derived from the early versions of the
DelegatingXxx types found in the Jakarta-Commons DBCP component, as

(2.1) identify the base name for the component


(Names like "JDBC Proxy" are avoided since JDBC is a registered trademark
of Sun.)

(2.2) identify the coding conventions for the component

The code will follow the standard Sun coding conventions or
other/additional conventions as determined by the committers.

(3) identify any Apache, DB, or DB Commons resources to be created

(3.1) mailing list

The component will use the general DB Commons lists for communication.

(3.2) source repositories

The component will use a <code>jdbp</code> directory of the db-commons
module in CVS.

(3.3) issue tracking

The component will be listed as a component of the DB Commons Bugzilla

(3.4) web site

The component's web site will be located at

(4) identify the initial set of committers

 * Rodney Waldhoff
 * any additional db-commons committer who wishes to join in

View raw message