Re: Unregistering the driver from DriverManager

If the only concern is OSGi environments, I think that unregistering could
be handled in a BundleActivator
<http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleActivator.html>.stop()
implementation bundled with the driver.

See pending issue #71 <https://github.com/pgjdbc/pgjdbc/issues/71> on
Github.

2014-12-29 12:48 GMT+01:00 Dave Cramer <pg(at)fastcrypt(dot)com>:

> I have no objection to an unregister static method being added. It's not
> in the API so it would not effect anything really
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
> On 29 December 2014 at 04:53, Christopher BROWN <brown(at)reflexe(dot)fr> wrote:
>
>> 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
>>
>>
>