Unregistering the driver from DriverManager

Hello,

I'm starting to integrate the Postgresql JDBC driver into an OSGi
environment, as an OSGi bundle. I'm evaluating the different ways to avoid
a classloader leak with DriverManager when hot-swapping the driver bundle
without restarting the host application, and am seeking suggestions on best
practice regarding the Postgresql JDBC driver.

Another bundle (which I provide, it's not third-party) will directly depend
upon it (loading classes directly, namely org.postgresql.Driver); when the
Postgresql JDBC driver classes are loaded, the other bundle will create a
DataSource using a JDBC connection pool, and register the DataSource as an
OSGi service. Normally, that's all that will happen during the application
lifecycle, but in principle, it's possible for the administrator to want to
replace say the 9.3 driver with the 9.4 driver by removing the 9.3 ".jar"
at runtime, and replacing it with the 9.4 ".jar", all at runtime; when the
first ".jar" is deleted, the dependent bundle is knocked offline,
unregistering the DataSource automatically, and notifying all clients; when
the second is installed, the application is once again fully-functional
(and all this normally occurs within a few hundred milliseconds).

Looking at the source code, I can see that the org.postgresql.Driver class
registers itself in a "static" block with DriverManager (which is the
correct behavior regarding the JDBC spec). However, short of a brute-force
loop -- like this one: http://stackoverflow.com/a/5315467 (enhanced to
check the class name of each driver, to avoid clobbering unrelated driver
registrations) -- is there any other approach possible or that could be
added, say a NonRegisteringDriver (superclass of Driver, with all logic
except for the static initializer) or an "unregister()" static method, or a
field containing the registered Driver instance?

Thanks,
Christopher