Re: context classloader

From: Vadim Nasardinov <vadimn(at)redhat(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: context classloader
Date: 2005-01-19 03:08:21
Message-ID: 200501182208.21287@vadim.nasardinov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

On Tuesday 18 January 2005 18:07, Oliver Jowett wrote:
> I am of the opinion that thread context classloaders are evil

If that's a moral judgment, I have no comment. If a technical one --
where's the evidence? (My ignorance prevents me from taking sides in
this argument. I'm just curious.)

> and should be avoided if at all possible -- they make code fragile
> and sensitive to caller context (almost by definition!)

It doesn't have to be any more sensitive than the current situation.
Current code is also sensitive to caller context. The Driver.class's
classloader depends on the caller. The thrust of your argument seems
to be that this is a one-time dependency. Once established, it
doesn't changed for the remainder of the class's lifecycle.

Well, the same could be true of a context-classloader-based
implementation.

When you register the Driver instance with the DriverManager in the
static initializer, a (weak) reference to the current context
classloader may be saved in a static field. The field can be used
later on in the getDefaultProperties() method, if
getClass().getClassLoader() turns out to be null. (BTW, couldn't this
be Driver.class.getClassLoader() instead?)

> Does it make sense to have the driver defaults change depending on
> who is obtaining the connection?

The fact that this is nonsensical is irrelevant. Changing defaults on
a per connection basis has never been proposed.

More to the point, can someone explain what
/org/postgresql/driverconfig.properties files are actually used for?
Google doesn't seem to know:
http://www.google.com/search?q=%22driverconfig.properties%22

Without knowing what this feature is actually used for, I'd speculate
groundlessly that the context-classloader-based implementation is more
likely to work in the application server scenario. Within the same
app server instance, multiple *.properties files are likely to exist
for use by different apps. These files aren't likely to be on the
CLASSPATH. Rather, they're likely to be in a per-application config
directory that the system classloader can't see.

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Oliver Jowett 2005-01-19 04:12:59 Re: context classloader
Previous Message Oliver Jowett 2005-01-18 23:07:48 Re: context classloader