RE: JDBC version problems
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 satisfiedexcept 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]
Re: JDBC version problems
I think that I will abandon writing a log4j connection pooling class and
instead suggest that users use the commons-dbcp package. I looked it
over and it does not require anything special from the client code;
everything is configured at run-time. Therefore there should be no
issue with using the UrlConnectionSource already in the sandbox with the
commons-dbcp package to get connection pooling. Then we can let
commons-dbcp worry about JDBC versions and such.
To be truthful, I was a little reluctant to take on this effort to begin
with because I suspected a production worthy implementation might be a
significant effort. On the other hand, the wind has been knocked out of
my sails a little bit...
Ceki Gülcü wrote:
Apparently the problem is quiet old:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01282.html
It was recently discussed on commons-dev
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=101538994027435&w=2
My suggestion would be to ask on [EMAIL PROTECTED] to see whether the
problem was already adressed.
At 08:11 PM 8/9/2003 +0200, you wrote:
Ray,
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 satisfiedexcept 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]
Re: JDBC version problems
Ray,
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
satisfiedexcept 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]
RE: JDBC version problems
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 satisfiedexcept 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]
Re: JDBC version problems
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
satisfiedexcept 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]
--
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]
Re: JDBC version problems
Apparently the problem is quiet old:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01282.html
It was recently discussed on commons-dev
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=101538994027435&w=2
My suggestion would be to ask on [EMAIL PROTECTED] to see whether the problem
was already adressed.
At 08:11 PM 8/9/2003 +0200, you wrote:
Ray,
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 satisfiedexcept 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]
--
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]
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 satisfiedexcept 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]
