> conceptually, you should be able to bind an object factory into one of
> these, but I've never tried it. The other approach would be to write your
> own implementation of javax.naming.Context and set the appropriate system
> properties to use your version -- details in the JNDI spec and tutorials.
Nah, I was just seeing if I could just use the same database lookup code in
a container deployed system as I could with a standalone app. Its not hard
to write the extra code and have an abstract class defining common
functionality across both implementations.
> J2EE describes the overall application development and installation
> process in terms of roles, and (in particular) defines a "deployer" role
> where the responsibility is to resolve all of the "resource references" in
> a deployment descriptor to match up to the actual resources to be used.
Very handy, thanks for the info.
> connection pool actually does -- it pools a set of java.sql.Connection
> objects. In the usual case, there will be some sort of TCP socket nested
> inside that connection for use in communicating to the real database -- so
> you can't share Connection instances across different JVMs anyway.
Doh! Obviously....I completely forgot about that.
> is "yes". I'm not sure what different it makes to an application, though;
> the J2EE platform standard is to access a java.sql.DataSource instance
> from your JNDI naming context, which DBCP already supports. (See the J2EE
> platform specification for dteails.)
With new JDBC specs you can do stuff like:
DataSource ds = context.lookup("jdbc/whatever");
if (ds instanceof ConnectionPoolDataSource)
{
/* return a connection from the pool: */
PooledConnection pc = ds.getPooledConnection();
Connection conn = pc.getConnection();
return conn;
}
else /* return a non-pooled connection */
return ds.getConnection();
I think the above was created to solve problems that the DBCP developers had
already solved via their own methods. What this achieves, I'm not exactly
sure, but I'm sure the Java folks created it for a reason...
> Craig
Thanks so much for your info and timely reply. You are a great help!
Les
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
