To draw a line under this thread, here are my takeaways.
The purpose of org/postgresql/driverconfig.properties is to globally
configure the driver. The most consistent way to do this is to put
the config file on the same path as the driver's .jar file.
There are two distinct classes of users:
(a) Those who have complete control over deployment of both the
driver and the application that uses it.
(b) Those who have limited control over their application's
classpath. (For a recent example, see [1].)
For Class A, the most consistent approach is to say,
(a) Don't put pgsql-jdbc.jar on the boot classpath. No reason to do
this.
(b) If you want to configure the driver globally, put
org/postgresql/driverconfig.properties in the same location as
the pgsql-jdbc.jar file.
For this class of users, then, the following works fine:
if (getClass().getClassLoader() != null) {
// load the config file
}
For Class B, the most consistent approach is to say, Since you don't
have control over the driver's .jar file location, you're not meant to
have control over its global settings. The same code works for this
class of users as well.
Defaulting to the system classloader strikes me as a fairly arbitrary
way to avoid an NPE. I agree that using the context class loader is
an equally arbitrary cop-out.
On Friday 21 January 2005 15:07, Oliver Jowett wrote:
> Well, the case that triggered this thread happened by putting the
> driver jar in a particular directory that apparently was in the
> appserver's bootstrap classpath. It's not common, but I don't see
> why the driver should break if it happens.
It shouldn't break. To prevent it from breaking, test the object for
nullity before calling a method on it.
Footnotes
1. http://archives.postgresql.org/pgsql-jdbc/2004-12/msg00212.php