Re: context classloader - Mailing list pgsql-jdbc

On Wednesday 19 January 2005 15:53, Oliver Jowett wrote:
> Firstly, your statement is not true. getClass().getClassLoader()
> will always return the classloader that was used to load the driver
> class, which *is* predictable.

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

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

Not always, you can't.

> 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?


> Secondly, I think you missed my point. It is the *timing* of
> initialization that I am concerned about. Timing of class
> initialization is hard to predict; how do you make sure that the CCL
> is correctly set when this happens?

I think I understood your point the first time around.  My
counterpoint is, the current getClass().getClassLoader() approach is
in a very similar boat.  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?

> How do you document this so that users don't get confused?

As the first step, documenting the existence of
driverconfig.properties would be nice.   Other than
  http://archives.postgresql.org/pgsql-jdbc/2004-10/thrd2.php#00023

is it mentioned anywhere else?  Does anyone actually use this?

> It seems unreasonable to require someone who just wants to use the
> JDBC driver to have to understand the mechanics of class
> initialization and guard against accidentally causing initialization
> before they're ready!

It's an argument I wholeheartedly agree with.  I'd just like to point
out that it also applies to the current situation.


> It could do that (it does that if the system classloader is null)
> but it seems less useful -- why can the driver suddenly no longer
> load defaults if it ends up in the bootstrap classpath?

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.



Thanks for taking the time to answer my questions.


Vadim