That is a good suggestion. Just make sure that commons-logging is not a direct or even indirect dependency of commons-dbcp.
I'd even go as far as asking the developers of the various dependency packages if they plan to use commons-logging in the near future.
At 10:08 AM 8/9/2003 -0700, Scott Deboy wrote:
I haven't looked at the api to see if it works across versions, but have you checked out:
http://jakarta.apache.org/commons/dbcp/ ?
-----Original Message----- From: Raymond DeCampo [mailto:[EMAIL PROTECTED] Sent: Sat 8/9/2003 9:52 AM To: Log4J Developers List Cc: Subject: Re: JDBC version problems 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]
--------------------------------------------------------------------- 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]
