Have you considered using jdbc-2.0jar as commons-dbcp has done?
At 12:52 PM 8/9/2003 -0400, you wrote:
But the problem isn't the methods, but the new classes. For example, one of the new methods on Connection is:
Savepoint setSavepoint();
No matter what the implementation of this method is, the 1.2 JRE will not supply a Savepoint class. That will prevent the the Connection implementation from loading (unless the Savepoint class is supplied in another fashion).
Ceki Gülcü wrote:Assuming your connection pool implementation encapsulates an underlying connection object, one way to deal with method X that exists in version 1.4 and not in 1.2 of Connection interface is as follows: 1st variant ----------- Implement method X without actually calling the X method on the underlying connection. MyPooledConnecion implements Connection { .... void X(...) { throw new Exception("Method X cannot be called."); } The advantage of this approach is that it would compile on all JDK versions. As long as method X is not actually used we are safe. 2nd variant ----------- Same as the 1st variant for version 1.2 except that method X of the underlying connection object is called using reflection under v. 1.4. HTH,
At 11:19 AM 8/9/2003 -0400, Raymond DeCampo wrote:
Hello all,
As some of you know, I've been working on JDBC-based appenders in the sandbox. I wanted to create a connection pool for environments where no such pool existed so that the JDBC appender would not have to create a new connection for every log message.
If you've never thought about JDBC connection pooling, the typical way to implement this is to create an implementation of java.sql.Connection that delegates (almost) all of the calls to another Connection object. When the client requests a Connection object, it gets one of these delegates from the pool. It uses it just like any other Connection object and never needs to know about the pooling. When the client calls close() on the connection, it is not really closed, but returned to the pool.
That is all well and good until you try to create an implementation java.sql.Connection that will work for Java 1.2 and up. The Connection interface has new methods on it for 1.3 and 1.4. No big deal, when you compile against 1.2 it won't care because the original interface will be satisfied....except that in 1.4 there are new classes (e.g. java.sql.SavePoint) referenced by the new methods. If you try to compile with 1.2, it will say, java.sql.SavePoint? never heard of it...
Does anybody have a solution to this? I'm not there is a good one...even if we do a conditional compilation somehow we would need to distribute a version of log4j for each Java version. (Because if you try to run a 1.4 compiled Connection implementation on a 1.2 JRE, there will be no SavePoint class and the class won't load. If you try to load a 1.2 compiled Connection implementation on a 1.4 JRE it will say you don't really implement the Connection I have...)
So, unless someone has a brilliant idea I guess I will abandon this idea for now...
Ray
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Ceki For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
