logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond DeCampo <rdeca...@twcny.rr.com>
Subject Re: JDBC version problems
Date Sat, 09 Aug 2003 16:52:50 GMT
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: log4j-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

View raw message