proxool-developer — Developer's discussion list

Re: [Proxool-developer] configuration via properties file

[Bruce S. <fe...@fr...>]

This one time, at band camp, Bas Cancrinus said:

BC>Bill Horsman wrote:
BC>> Does anyone have any thoughts of whether we should include the
BC>> XMLConfigurator in the binary distribution? Doing so would mean a
BC>> dependence for everyone on JAXP and a compliant parser. I must admit,
BC>> I'm tempted to do it...
BC>
BC>I'd like to propose the distribution of 2 jars: one that contains the 
BC>basic proxool driver and another that contains your convenience classes. 
BC>That'll make things conveniently arranged.
BC>
BC>Kind regards,
BC>Bas

How about just an Ant task to do this for you. That way if you don't
want two jars in your environment, there's no hard requirement for it.

Bruce
-- 
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'

Re: [Proxool-developer] configuration via properties file

[Bas C. <ba...@ci...>]

Bill Horsman wrote:
> Does anyone have any thoughts of whether we should include the
> XMLConfigurator in the binary distribution? Doing so would mean a
> dependence for everyone on JAXP and a compliant parser. I must admit,
> I'm tempted to do it...

I'd like to propose the distribution of 2 jars: one that contains the 
basic proxool driver and another that contains your convenience classes. 
That'll make things conveniently arranged.

Kind regards,
Bas

-- 
Bas Cancrinus   -> ba...@ci...
Software Architect
Cipherware Ltd. -> http://www.cipherware.com

Re: [Proxool-developer] JDK 1.2

[Bas C. <ba...@ci...>]

Bill Horsman wrote:
> What do people think about dropping 1.2 support? Or, alternatively,
> fully testing Proxool 0.5 against JDK 1.2 and then just letting 1.2
> users use that one (and requiring JDK 1.3+ for Proxool 0.6)?

In my opinion the time has come to drop 1.2 support. Our product - which
will depend on the proxool jar - requires Sun's JRE 1.3.1.

Bas

-- 
Bas Cancrinus   -> ba...@ci...
Software Architect
Cipherware Ltd. -> http://www.cipherware.com

[Proxool-developer] JDK 1.2

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

I quietly dropped the JDK 1.2 binary from the last release (0.5). We
still support it with the source distribution but it is increasingly
drifting away from the JDK 1.3+ code. I don't run unit tests on it any
more (although I should). 

We provide JDK support by using Ant to use some different source files
for certain classes (the ones that use the Proxy class). This is a
pretty nasty solution, IMHO).

What do people think about dropping 1.2 support? Or, alternatively,
fully testing Proxool 0.5 against JDK 1.2 and then just letting 1.2
users use that one (and requiring JDK 1.3+ for Proxool 0.6)?

Regards,
Bill

Re: [Proxool-developer] configuration via properties file

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

Bruce,

On Tue, 2002-12-10 at 00:15, Bruce Snyder wrote:

> PoolMan provides both programmtic as well as properties file
> configuration. Can Proxool be configured via a properties file? If so, is
> there any documenation on this? 

We do have a PropertyConfigurator and an XMLConfigurator in the source
download although there is no documentation for it at this stage.

We realise how important ease of configuration is and I would like to
see this part of release 0.6 which is due sometime between December 13
and 20. (That is, the PropertyConfigurator to be included in the binary
and to add documentation to the web site).

Does anyone have any thoughts of whether we should include the
XMLConfigurator in the binary distribution? Doing so would mean a
dependence for everyone on JAXP and a compliant parser. I must admit,
I'm tempted to do it...

Bruce, would you like to be more critical of the web site? Other than
property file documentation, was there anything else that you found
lacking. The web site is really important I believe; if people don't
find the information they want quickly they are unlikely to bother to
mail the developer list to find out.

Regards,
Bill

[Proxool-developer] configuration via properties file

[Bruce S. <fe...@fr...>]

PoolMan provides both programmtic as well as properties file
configuration. Can Proxool be configured via a properties file? If so, is
there any documenation on this? 

Bruce
-- 
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'

RE: [Proxool-developer] Release 0.5

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

Martin,

On Mon, 2002-12-09 at 15:24, Martin Crawford wrote:

> We use PreparedStatements in a few places, although, I would trust that I've
> tested them yet.

"not tested"?

> If you setup the tests I'd be happy to run them against my PostgreSQL
> server, or if you want offline I could offer you to connect to ours over SSH
> to get you going.

Let me look into adapting one of the tests we already have so that you
can run it against your db.

> The PostgreSQL install is really easy if you follow the documentation.
> Although, there are a few gottchas and the most important for testing the
> jxdbcon driver is that it does not support the latest version 7.3 which was
> just released a couple weeks ago. The jxdbcon team are work on supporting
> 7.3 as we speak.

Thanks for the tips.

Bill

RE: [Proxool-developer] Release 0.5

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

Martin,

On Mon, 2002-12-09 at 15:07, Martin Crawford wrote:

> > (On that note, I'm going to add a line to the log that shows what
> > version is being run.)
> 
> However, I did not received anything in my stdout (as I have not setup any
> logging) to show the version.

Hehe. I haven't actually done that yet... I will do soon though, I
promise.

> But it works, so you're onto the problem then. If there is anyhting else
> you'd like me to try let me know.

It works? Hmm, all I did was add debug code. I think we must have got
confused with jars somewhere along the line. (Which isn't to suggest it
was you :)

I've just spent some time trying to setup jxdbcon (easy) and I'm now
reading Postgres doc to set that up too. (I currently run MySQL on
Linux). But perhaps I won't bother then... Tell me, do
PreparedStatements and CallableStatements work too?

0.6 is scheduled for the end of the week. To include this fix for
abstract statements and j2ee jdbc compliance.

Regards,
Bill

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

Re: [Proxool-developer] Release 0.5

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

Hi Bas,

> Wait! We have a request for 0.6: J2EE compliant drivers are not allowed 
> to access System properties. Could you replace the following code?
> 
> proxool-0.5\src\java\org\logicalcobwebs\proxool\ReloadMonitor.java/64: 
>     System.setProperty(LOAD_TIME_PROPERTY, 
> String.valueOf(System.currentTimeMillis()));
> ----------------------------------------
> proxool-0.5\src\java\org\logicalcobwebs\proxool\ReloadMonitor.java/92: 
>          return Long.parseLong(System.getProperty(LOAD_TIME_PROPERTY));

We have plenty of time to include that in 0.6. If I can just work out
what I'm going to replace it with... I'll have an experiment. Thanks for
spotting that uncompliance. It would be good to say that we are fully
compliant.

> BTW: The exception that was thrown during the J2EE 1.3.1 CTS tests was 
> caused by JDBC 3.0 API calls. We'll now test with the 1.2.1 CTS, which 
> tests against the JDBC 2.0 API. Please expect our results early next week.

Great.

Regards,
Bill

RE: [Proxool-developer] Release 0.5

[Martin C. <mus...@us...>]

Bill,

> I've taken a look at the code and I see the problem. Their Statement
> implementation doesn't implement Statement directly but extends an
> abstract class that does so. This exposes a limitation in Proxool's code
> that I have now fixed. The latest CVS copy should now work for jxDBCon
> driver using methods to create Statements, PreparedStatements and
> CallableStatements.

Right, this is the whole concept for the jxDBCon framework. I guess not many
drivers make use of abstraction? I find this driver to be a better/cleaner
implementation for PostgreSQL than the one that actually ships with the
database.

> For your convenience I have I built a JAR:
>
>  http://proxool.sourceforge.net/download/proxool-CVS.jar

Again thanks for providing binaries. I feel lazy;) I think it's time I get a
copy and compile myself from source.

> Don't bother with that now. Just let me know whether the new version
> fixes it for you. I suspect it will.

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.

I'm in not hurry to upgrade 0.4 works perfectly fine for me. But, I am happy
to help test this one. I was easily able to build from source so we can
begin the debugging mayhem! My company is actively developing a servlet
application using proxool, so it's very easy for me to drop in a new version
during the development cycle. Again 0.4 works perfect for us so we're in no
panic.

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...

Thanks again for being so helpful.
Martin

Re: [Proxool-developer] Release 0.5

[Bas C. <ba...@ci...>]

Bill Horsman wrote:

> 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.

Wait! We have a request for 0.6: J2EE compliant drivers are not allowed 
to access System properties. Could you replace the following code?

proxool-0.5\src\java\org\logicalcobwebs\proxool\ReloadMonitor.java/64: 
    System.setProperty(LOAD_TIME_PROPERTY, 
String.valueOf(System.currentTimeMillis()));
----------------------------------------
proxool-0.5\src\java\org\logicalcobwebs\proxool\ReloadMonitor.java/92: 
         return Long.parseLong(System.getProperty(LOAD_TIME_PROPERTY));

BTW: The exception that was thrown during the J2EE 1.3.1 CTS tests was 
caused by JDBC 3.0 API calls. We'll now test with the 1.2.1 CTS, which 
tests against the JDBC 2.0 API. Please expect our results early next week.

Kind regards,
Bas

-- 
Bas Cancrinus   -> ba...@ci...
Software Architect
Cipherware Ltd. -> http://www.cipherware.com

RE: [Proxool-developer] Release 0.5

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

Further to my earlier email:

On Fri, 2002-12-06 at 12:02, Bill Horsman wrote:

> > > What JDBC driver are you using?
> > 
> > https://sourceforge.net/projects/jxdbcon/ (0.9z which is the latest)
> 
> That's useful to know. I might take a peek at the code if we don't get
> to the bottom of this soon.

I've taken a look at the code and I see the problem. Their Statement
implementation doesn't implement Statement directly but extends an
abstract class that does so. This exposes a limitation in Proxool's code
that I have now fixed. The latest CVS copy should now work for jxDBCon
driver using methods to create Statements, PreparedStatements and
CallableStatements. 

For your convenience I have I built a JAR:

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

> If you
> can spare a little time I'd like to try and pursue it for a little (and
> if I fail to work out the root cause then we can add the hack). I've
> added some debug code to the offending section so that we can see
> exactly what's going on. Would you mind testing this new jar (which
> doesn't have the fix in) and letting me know the results?

Don't bother with that now. Just let me know whether the new version
fixes it for you. I suspect it will.

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. 

Regards,
Bill

RE: [Proxool-developer] Release 0.5

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

Martin,

On Thu, 2002-12-05 at 15:25, Martin Crawford wrote:

> > http://proxool.sourceforge.net/download/proxool-cvs-debug.jar
> >
> 
> This didn't seem to have the debugging information when I tried it.

Hmm. I just tried it (downloaded it from that link) and it worked for
me. Are you sure you have removed the old jar from your classpath? Just
to be absolutely clear, I expect that jar to include line numbers in the
stack trace (I'm sure you knew that though :)

> > What JDBC driver are you using?
> 
> https://sourceforge.net/projects/jxdbcon/ (0.9z which is the latest)

That's useful to know. I might take a peek at the code if we don't get
to the bottom of this soon.

> Fixed! If you would like the stack track for more information let me know.

That's good. We've identified the problem. But not entirely fixed it I'm
afraid. As it is, all sub-classes of Statement (like CallableStatement)
will not work correctly. There are two options, hack the code to work
with all sub-classes too; or try to work out why the original code
(which works with other JDBC drivers) doesn't work for jxdbcon. If you
can spare a little time I'd like to try and pursue it for a little (and
if I fail to work out the root cause then we can add the hack). I've
added some debug code to the offending section so that we can see
exactly what's going on. Would you mind testing this new jar (which
doesn't have the fix in) and letting me know the results?

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

You should see some debug output along the lines of:

  delegateStatement: java.sql.Statement
  proxiedStatement: java.sql.Statement

> Thanks for the speedy fix/response!

No problem.

Bill

RE: [Proxool-developer] Release 0.5

[Martin C. <mus...@us...>]

Bill,

First of all thanks for the detailed response.

>
> http://proxool.sourceforge.net/download/proxool-cvs-debug.jar
>

This didn't seem to have the debugging information when I tried it.

> (Maybe we should create all the JARs with debug
> information in until we get to 1.0...)

Maybe just have a debug version available for download. Some people might
already be using proxool in production. Or hopefully most people are not as
lazy as me and will compile themselves;)

> What JDBC driver are you using?

https://sourceforge.net/projects/jxdbcon/ (0.9z which is the latest)

>
> http://proxool.sourceforge.net/download/proxool-crawford.jar
>

Fixed! If you would like the stack track for more information let me know.

Thanks for the speedy fix/response!
Martin

RE: [Proxool-developer] Release 0.5

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

Hi Martin,

On Wed, 2002-12-04 at 18:58, Martin Crawford wrote:

> Just upgraded to proxool-0.5 on a webapp using tomcat 4.0. I'm using the Sun
> Java SDK 1.4.0.
> 
> Everything worked fine with proxool-0.4, but the upgrade throws the
> following exception:
> 
> java.lang.ClassCastException: $Proxy2
> 	at $Proxy1.createStatement(Unknown Source)

Knowing the line that it occurred on would be really handy. Would you
mind picking up this jar file that is compiled with debug information:

http://proxool.sourceforge.net/download/proxool-cvs-debug.jar

Or, failing that, compile from source. Then I will know what line is
causing the problem. (Maybe we should create all the JARs with debug
information in until we get to 1.0...)

> I've attached my driver initialisation code 

Which looks fine.

> The stack trace shows that my exception occurs when calling
> Connection.createStatement(). 

The createStatement method is called a lot during our unit tests (as
you'd expect) and it seems to work fine.

> Perhaps a VM or JDBC version issue? 

I think the VM should be okay. What JDBC driver are you using? 

>   try {
>     // Register the JDBC driver
>     Class.forName(sJdbcDriver);
>   } catch (Exception e) {
>     throw new SQLException("Cannot find JDBC driver: " + sJdbcDriver);
>   }

For what it's worth, Proxool registers the delegate JDBC driver for you.
But it doesn't do any harm to do it twice.

---

I've had a quick review of the code that could be responsible and I have
tried doing the creation of the Statement proxy a slightly different
way:

diff -r1.5 ProxyFactory.java
54c54,55
<         return
Proxy.newProxyInstance(delegate.getClass().getClassLoader(),
delegate.getClass().getInterfaces(), new ProxyStatement(delegate,
connectionPool,
proxyConnection, sqlStatement));
---
>         Class[] interfaces = {Statement.class};
>         return
Proxy.newProxyInstance(delegate.getClass().getClassLoader(), interfaces,
new ProxyStatement(delegate, connectionPool, proxyConnection,
sqlStatement));

I have built another JAR that includes that experimental fix:

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

Let me know if that fixes it. Or if it doesn't, the full stack trace for
the ClassCastException.

Regards,
Bill

RE: [Proxool-developer] Release 0.5

[Martin C. <mus...@us...>]

Bill,

Just upgraded to proxool-0.5 on a webapp using tomcat 4.0. I'm using the Sun
Java SDK 1.4.0.

Everything worked fine with proxool-0.4, but the upgrade throws the
following exception:

java.lang.ClassCastException: $Proxy2
	at $Proxy1.createStatement(Unknown Source)

I've attached my driver initialisation code incase there is a new
configuration that I missed, although this appears to work alright. The
stack trace shows that my exception occurs when calling
Connection.createStatement(). Perhaps a VM or JDBC version issue? I
downloaded the jar, I have not compiled from sources.

Thanks.
Martin


  // Get the init url parameter
  String sJdbcUrl= oContext.getInitParameter("JDBC_URL");
  String sJdbcDriver = oContext.getInitParameter("JDBC_DRIVER");
  String sJdbcPoolMaxConn=
oContext.getInitParameter("JDBC_POOL_MAX_CONNECTIONS");
  String sJdbcPoolMinConn=
oContext.getInitParameter("JDBC_POOL_MIN_CONNECTIONS");
  String sJdbcPoolTestSql= oContext.getInitParameter("JDBC_POOL_TEST_SQL");

  Properties oProperties = new Properties();
  oProperties.setProperty("proxool.maximum-connection-count",
sJdbcPoolMaxConn);
  oProperties.setProperty("proxool.maximum-new-connections",
sJdbcPoolMinConn);
  oProperties.setProperty("proxool.house-keeping-test-sql",
sJdbcPoolTestSql);

  m_sJdbcUrl = "proxool:" + sJdbcDriver + ":" + sJdbcUrl;

  try {
    // Register the connection pool
    Class.forName(JDBC_CONNECTION_POOL_DRIVER);
  } catch (Exception e) {
    throw new SQLException("Cannot find JDBC Connection Pool driver: " +
JDBC_CONNECTION_POOL_DRIVER);
  }

  try {
    // Register the JDBC driver
    Class.forName(sJdbcDriver);
  } catch (Exception e) {
    throw new SQLException("Cannot find JDBC driver: " + sJdbcDriver);
  }

  Connection oConnection = DriverManager.getConnection(m_sJdbcUrl,
oProperties);

  if (oConnection != null) {
    m_bInitialised = true;
    return(oConnection);
  }
  throw new SQLException("Unable to initialize JDBC Connection Pool");

[Proxool-developer] Release 0.5

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

Hi all,

Released 0.5 last night. Some last minute changes to do with fatal sql
exceptions (it wasn't working). I don't think it caused any knock on
effects and all the unit tests worked okay. But I have a cautious,
worried feeling at the back of my mind. Please let me know how it
behaves.

Release 0.6 should happen in a few weeks. It will include some new stuff
relating to persistent configurators. The goals now are bug fixes,
improved documentation and ease of configuration. 

Any feedback on the new web site would be good. Bas, I messed around
with your "quick start" page a little so that it fitted in with the rest
of the doc without too much duplication.

Regards,
Bill

Re: [Proxool-developer] JDBC API TestSuite 1.3.1 failure

[Alastair C. <ala...@ci...>]

Hello Bill,

I am a colleague of Bas in Cipherware.  I have run the tests several 
times and I hope that we'll soon have an intelligent result - here are 
some thoughts about the tests so far.

Bill Horsman wrote:

>>The TestSuite repeats all test sets in 4 batches or so, to make sure 
>>that the driver is consistent. When the TestSuite enters the second 
>>batch it starts repeating the following stack trace:
>>
>>java.lang.NoClassDefFoundError
>>     at
>>org.logicalcobwebs.proxool.ConnectionPool.<init>(ConnectionPool.java:101)
>>    
>>
>
>I don't understand that at all. Line 101 in ConnectionPool is:
>
>    reloadMonitor = new ReloadMonitor(definition.getName());
>
>Obviously, that class does exist since it is found the first time. I am
>a little suspicious because the responisibility of that class is to spot
>Proxool being reloaded (which can sometimes cause duplicate static
>instances depending on what container is doing the reload). But I can't
>see any code that would result in a class not being found! (Nor do I
>know what code would cause that).
>
The class is always found for the first batch of tests, but not on any 
subsequent tests, so I share your suspicion about the container.  On 
previous occasions, there were problems with the SecurityManager, which 
is so restrictive that it even prevented setProperty in Proxool.  I can 
understand why the setting would be restrictive within J2EE - it is 
called by remote clients - but not for the driver, which is only called 
by J2EE.  I changed all security settings to java.security.AllPermission 
(only for the tests of course) and this was the new result.

>
>How many times does that error appear? 
>
It appears for all tests except the first one.

>Why does the test suite report "ERROR: An error occurred while closing
>the database connection" whilst the stack trace seems to be related to
>creating a new connection pool?
>
This second error only occurs because the connection has not been opened 
in the first place.

>What is the reload mechanism between batches. Does the test suite
>attempt to reload the classes? (I'm a little hazy about reloading
>classes, JVMs and such). Or does it remove the connection pool and start
>again (without any JVM or class reload stuff)?
>
I'm not sure either.  There is very little support for, and no 
discussion groups about CTS testing.  I suspect that it loads the 
connection pool from within J2EE the first time and then reloads them 
from the CTS client after that.  This is because the jar has to be in 
two places: in $J2EE_HOME/lib/system and in the CLASSPATH of CTS, which 
is defined in the file $CTS_HOME/bin/cts_env

>I'm glad your looking into this. Proxool can only benefit from intensive
>testing like this. I'm confident that this problem is not appearing in
>production situations at the moment, but I still think it is very worth
>while getting to the bottom of this.
>  
>
We tested Proxool with our software, Ci-Access, and it worked perfectly. 
 I now intend to run CTS to test Ci-Access and Proxool together, to see 
if the same error occurs.  I'm afraid that we won't be ready for release 
0.5 of Proxool as the tests take about 6 hours to complete, but I hope 
to have it ready for release 0.6.

I'll keep you posted!

Kind regards,
Alastair

Re: [Proxool-developer] JDBC API TestSuite 1.3.1 failure

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

Bas,

On Fri, 2002-11-29 at 10:57, Bas Cancrinus wrote:

> In principle Proxool may be compliant, because all test 
> sets are passed the first time.

:-D

> The TestSuite repeats all test sets in 4 batches or so, to make sure 
> that the driver is consistent. When the TestSuite enters the second 
> batch it starts repeating the following stack trace:
> 
> java.lang.NoClassDefFoundError
>      at
> org.logicalcobwebs.proxool.ConnectionPool.<init>(ConnectionPool.java:101)

I don't understand that at all. Line 101 in ConnectionPool is:

    reloadMonitor = new ReloadMonitor(definition.getName());

Obviously, that class does exist since it is found the first time. I am
a little suspicious because the responisibility of that class is to spot
Proxool being reloaded (which can sometimes cause duplicate static
instances depending on what container is doing the reload). But I can't
see any code that would result in a class not being found! (Nor do I
know what code would cause that).

How many times does that error appear? 

Why does the test suite report "ERROR: An error occurred while closing
the database connection" whilst the stack trace seems to be related to
creating a new connection pool?

What is the reload mechanism between batches. Does the test suite
attempt to reload the classes? (I'm a little hazy about reloading
classes, JVMs and such). Or does it remove the connection pool and start
again (without any JVM or class reload stuff)?


I'm glad your looking into this. Proxool can only benefit from intensive
testing like this. I'm confident that this problem is not appearing in
production situations at the moment, but I still think it is very worth
while getting to the bottom of this.

Regards,
Bill


>      at
> org.logicalcobwebs.proxool.ConnectionPoolManager.createConnectionPool(ConnectionPoolManager.java:62)
>      at
> org.logicalcobwebs.proxool.ProxoolFacade.registerConnectionPool(ProxoolFacade.java:58)
>      at
> org.logicalcobwebs.proxool.ProxoolDriver.connect(ProxoolDriver.java:66)
>      at java.sql.DriverManager.getConnection(DriverManager.java:512)
>      at java.sql.DriverManager.getConnection(DriverManager.java:172)
>      at ...
> 
> And the test suite says:
> ERROR: An error occurred while closing the database connection
> Test case throws exception: java.lang.NoClassDefFoundError
> 
> Do you have any idea what could cause this problem? Further details:
> - All Proxool properties remain their default value during the tests, 
> i.e. we haven't set any proxool.* properties.
> - Tested source is current CVS repository state.
> 
> Many thanks,
> Bas

[Proxool-developer] JDBC API TestSuite 1.3.1 failure

[Bas C. <ba...@ci...>]

Dear Bill,

Al has set up the TestSuite to run Proxool, wrapped around a compliant 
Oracle driver. In principle Proxool may be compliant, because all test 
sets are passed the first time.

The TestSuite repeats all test sets in 4 batches or so, to make sure 
that the driver is consistent. When the TestSuite enters the second 
batch it starts repeating the following stack trace:

java.lang.NoClassDefFoundError
     at
org.logicalcobwebs.proxool.ConnectionPool.<init>(ConnectionPool.java:101)
     at
org.logicalcobwebs.proxool.ConnectionPoolManager.createConnectionPool(ConnectionPoolManager.java:62)
     at
org.logicalcobwebs.proxool.ProxoolFacade.registerConnectionPool(ProxoolFacade.java:58)
     at
org.logicalcobwebs.proxool.ProxoolDriver.connect(ProxoolDriver.java:66)
     at java.sql.DriverManager.getConnection(DriverManager.java:512)
     at java.sql.DriverManager.getConnection(DriverManager.java:172)
     at ...

And the test suite says:
ERROR: An error occurred while closing the database connection
Test case throws exception: java.lang.NoClassDefFoundError

Do you have any idea what could cause this problem? Further details:
- All Proxool properties remain their default value during the tests, 
i.e. we haven't set any proxool.* properties.
- Tested source is current CVS repository state.

Many thanks,
Bas

-- 
Bas Cancrinus   -> ba...@ci...
Software Architect
Cipherware Ltd. -> http://www.cipherware.com