Re: context classloader

Vadim Nasardinov wrote:

> That part is predictable, yes. What's not predictable is which
> *particular* classloader this will be.

It is a different class of predictability. If you know where the driver
is loaded from, you know at least one location checked by the driver's
classloader -- the driver jar. You have no information about the CCL in
effect at driver load time, though.

>>You can always, for example, put driverconfig.properties in the path
>>of the same classloader that loads the driver
>
> Not always, you can't.

Why not? If you could put the driver jar there, why can't you also put
properties there?

>>In contrast, if you're relying on the CCL, you have essentially no
>>guarantees about where it will search. It could be a completely
>>unrelated CL that can't even see the driver jar!
>
> Why is that so terrible?

It's much less predictable. Given information on where the driver is
loaded from, you have no idea where it will load defaults from. At least
with using getClass().getClassLoader(), you know at least one location
(the driver jar's location), and can probably infer several more from
knowledge about how you configure classpaths to load the driver from.

> If one can put
> org/postgresql/driverconfig.properties on the same classpath as the
> driver, then, yes, they're all set. (Except for the bootstrap
> classloader case.) If they can't do that, then they're essentially in
> the same boat. How does one make sure that the classloader that loads
> org.postgresql.Driver is also the one that can find their
> driverconfig.properties?

Know your environment; supply a classpath for loading the driver that
includes a location that you can modify. e.g. add it to CLASSPATH, or
include it in the classpath-to-load-driver-from configuration, or put it
in the magic directory whose contents are included at startup, etc.

> I keep forgetting to ask. How do you put the driver in the bootstrap
> classpath? The only way that I know of is to use one of the following
> flags under Sun's JRE:
>
> -Xbootclasspath
> -Xbootclasspath/a
> -Xbootclasspath/p
>
> I was under the impression that using these is very uncommon.

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.

-O