ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian M. Savage" <>
Subject Re: [PATCH] Print SQL to System.out or output file
Date Wed, 27 Sep 2000 08:34:23 GMT
I don't mind the change - my benefit. Anyway, I thought there should be an
easier method to instantiate a class. Thanks for fixing the System.out
problem at the end. That wouldn't have been very funny (I didn't test it
well enough with output going to System.out because I'm more interested in
sending the results to a file). What's the difference between loadClass()
and forceLoadSystemClass()?

Thanks for the explanation about why using DriverManager doesn't work
directly. I'll have to re-read your explanation and see if I can implement
your solution for my own benefit when I have time.

My main reason for concern was the thought that instantiating it myself
might somehow be less portable or something. It works fine with jConnect 5.2
(Sybase) for me though.


----- Original Message -----
From: "Stefan Bodewig" <>
To: <>
Sent: Wednesday, September 27, 2000 4:55 PM
Subject: Re: [PATCH] Print SQL to System.out or output file

> >>>>> "JMS" == Julian M Savage <> 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

View raw message