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,