I made a patch locally to allow me to use DataSources from JNDI instead of the default Torque connection pool. I used the Adapter pattern (I think that's the word for it :-)) to preserve backward compatibility, turning pool/DBConnection and pool/ConnectionPool into interfaces and copying the existing classes to ConnectionPoolImpl and DBConnectionImpl. Then I added two new classes, DataSourceWrapper (implements ConnectionPool) and ConnectionWrapper (implements DBConnection), which wrap a DataSource and a java.sql.Connection and adapt them to the Torque APIs.
I also touched Torque.java to let me specify a database like database.mydatabase.resource=jdbc/MyDataSource There are three questions that I'd like to discuss here on this list -- - is this a reasonable approach? It seems like it would be better for all Torque code to use java.sql.Connection and javax.sql.DataSource directly, and eliminate ConnectionPool/DBConnection entirely, since JDBC 2 is the standard. This would break existing code, though, because all the generated classes expect Torque.getConnection() to return a DBConnection instead of a java.sql.Connection. - is there a good way to find out, at runtime, what database you're connecting to? When all you have is a DataSource and a JNDI resource name, you have no way of knowing the underlying database, which Torque needs to know to pick the right database adapter. Is there some magic JDBC query or escape that lets you figure out your database? (conn.getClass() doesn't work because it is usually wrapped by the pool, e.g., org.apache.commons.dbcp.PoolableConnection) - administrivia: what's the right way to submit a patch if there are new files that weren't in CVS before? Thanks, -- Bill -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
