ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@bost.de>
Subject Re: [PATCH] Print SQL to System.out or output file
Date Wed, 27 Sep 2000 07:55:43 GMT
>>>>> "JMS" == Julian M Savage <jsavage@fisci.com> writes:

 JMS> The part I'm slightly concerned about is that I don't use the
 JMS> DriverManager to get an instance of the driver, but instead
 JMS> instantiate the driver using either the built in class loader or
 JMS> the AntClassLoader depending on whether or not the user
 JMS> specifies a classpath.

I think the way you've done it is the easiest way around the
problem. I've been playing around with adding a classpath element to
<sql> myself yesterday and found why using DriverManager didn't work
by reading DriverManager's code.

In getConnection, DriverManager checks the ClassLoader associated with
this call (using some native magic) and tries to load the Driver once
again using this ClassLoader. If the class loaded by the "calling"
ClassLoader is different from the one specified to registerDriver, the
Driver is omitted. Comments indicate that this is considered a
security feature.

The ClassLoader associated with <sql> is the system class loader. So
if your Driver is not loadable by the system class loader,
DriverManager will skip it.

The solution I came up with involved a helper class that wrapped the
call to DriverManger.getConnection and loading this class via the
AntClassLoader so the "correct" ClassLoader would be calling the
method. Calling Driver.connect directly seems a lot clearer and easier
to grasp.

I've slightly modified your patch to use Class.newInstance instead of
searching for a no arg constructor and invoking that. Hope you don't
mind.

Stefan

Mime
View raw message