RE: [Proxool-developer] Release 0.5

[Bill H. <bi...@lo...>]

Hi Martin,

On Fri, 2002-12-06 at 21:02, Martin Crawford wrote:

> Sorry it didn't. Here is the stack trace:
> 
> Caused by: java.lang.RuntimeException: Unexpected invocation exception:
> $Proxy2
> 	at
> org.logicalcobwebs.proxool.ProxyConnection.invoke(ProxyConnection.java:114)
> 	at $Proxy1.createStatement(Unknown Source)
> 
> > Since nobody else has reported this problem I probably won't bother
> > making a new release early. 0.6 is scheduled for round about December
> > 12.

If you look at the following two lines:

LOG.error("Unexpected invocation exception", e);
throw new RuntimeException("Unexpected invocation exception: " +
e.getMessage());

The first one logs the trace of the original exception. The second one
throws a new exception to the user [of Proxool].

What I'm really interested in is the trace from the first one. And
you'll see that in the Proxool log. If you haven't cofigured that at all
it will be in stdout. If you've configured Logging at all (with, for
instance, Log4J) then it will be wherever you said it would be :)

> Perhaps you could share the differences between the 0.4 code and 0.5 code
> that would "break" abstraction of a Statement interface? Just for those
> curious...

In 0.5 we started proxying the Statement as well as the Connection. This
allows us to have better control over the behaviour of the Statement.
Like logging execution traces and times. And trapping SQLExceptions that
might prove fatal (to the Connection).

I've also just committed the code to add more debug to this problem. I
was pretty confident I'd fixed it so I'm now intrigued. Perhaps it is a
second problem appearing. But it's not very complicated so I'm sure we
can nail it. If I get time tomorrow I'll try and setup a jxDBCon test
environment. That would speed things along.

The binary is in the usual place:

  http://proxool.sourceforge.net/download/proxool-CVS.jar

It is quick for me to build binaries but it does add a layer of doubt to
bug fixing. If either one of us fails to copy the jar to the right place
then it would be easy for us to be testing the wrong version.

(On that note, I'm going to add a line to the log that shows what
version is being run.)

Regards,
Bill