Kathey Marsden <[email protected]> writes: > On 7/6/2011 9:35 AM, Knut Anders Hatlen wrote: >> >> We should, but we just shut down the engine, we don't deregister the >> driver in DriverManager, so the classes stay in memory forever. It's a >> bit tricky to get the old versions unloaded. Simply calling >> DriverManager.deregisterDriver() in the test tear-down won't work, since >> it'll only let you deregister drivers in the same class loader as the >> caller, and the test framework and the old drivers are loaded in >> different class loaders. >> > If we used DataSources for the upgrade tests would we avoid this > problem or would the autoloaded driver still get loaded?
I think we already use DataSources for the upgrade tests, see PhaseChanger#setUp(). In any case, EmbeddedDataSource will load EmbeddedDriver, which will register itself with the DriverManager. We can (maybe) change the EmbeddedDataSource to stop doing that, but we'd still have the problem in all the old versions we test against. One possible solution may be to create a helper class with a method that unloads the embedded driver and somehow wire this class into the class loader in which the old version is running. The helper class could be used from the test tear-down. Then we should be able to trick DriverManager into unloading the driver. I think... I've filed DERBY-5316 to track this issue. -- Knut Anders
