>>>>> "JMS" == Julian M Savage <[EMAIL PROTECTED]> 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
