Subject | Re: Unmanaged scenario |
---|---|
Author | kyle@kylecordes.com |
Post date | 2001-11-11T22:48:10Z |
--- In IB-Java@y..., "Massimo Ferrari" <massimo@r...> wrote:
describing the same thing I was in the thread a few weeks ago.
To really be a complete driver, it should be usable:
(A) via JCA
(B) with the JDBC 2.0 Optional Package API (DataSource, etc.)
(C) as a plain old non-Optional Package JDBC 2.0 driver.
Note that although the recommendation is to use DataSources, the
current JDK 1.3 SE documentation still gives examples of the
DriverManager mode of operation, and that appears to be the way we
are suppossed to do it with non-J2EE applications. DriverManager
does not appear to be not deprecated, either, since it's the only way
to get a Connection with the standard JDBC 2.0 API.
Is it hard to provide the "glue" code to support this API?
Kyle Cordes
www.kylecordes.com
> The main problem is that this driver is designed for the future(well, not
> bad :) ) but forgets the past...transparent as
> find that to make this driver really useful, JCA should be as
> possible (i.e. hidden) for the users that expect to use thislibrary as a
> JDBC driver only.Is there an echo in here? ;-) Massimo is doing a better job of
describing the same thing I was in the thread a few weeks ago.
To really be a complete driver, it should be usable:
(A) via JCA
(B) with the JDBC 2.0 Optional Package API (DataSource, etc.)
(C) as a plain old non-Optional Package JDBC 2.0 driver.
Note that although the recommendation is to use DataSources, the
current JDK 1.3 SE documentation still gives examples of the
DriverManager mode of operation, and that appears to be the way we
are suppossed to do it with non-J2EE applications. DriverManager
does not appear to be not deprecated, either, since it's the only way
to get a Connection with the standard JDBC 2.0 API.
Is it hard to provide the "glue" code to support this API?
Kyle Cordes
www.kylecordes.com