From: | "Chris Smith" <cdsmith(at)twu(dot)net> |
---|---|
To: | "Kris Jurka" <books(at)ejurka(dot)com> |
Cc: | <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: PATH: SSL flexibility and documentation |
Date: | 2004-02-19 03:20:18 |
Message-ID: | 044401c3f697$4d80ff20$6f00000a@KYA |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Kris Jurka wrote:
> Documentation additions should ideally be to the docbook source in
> the doc subdirectory.
Alright. I'll keep that in mind for the future.
As far as this patch, you've obviously thought about it and have the same
general idea as I do, so I'll let you take it from here. I have no vested
interest in this functionality, and I only wrote the patch on the chance that
no one else had gotten around to it and it seemed pretty trivial.
As to your specific comments:
> I was initially thinking about a
> setSSLSocketFactory(Object) for the non-ssl case which would do
> nothing, but allow code that tried to use this ssl option to compile
> and run consistently. That's not entirely consistent and perhaps
> setSSLSocketFactory should always take an Object parameter and
> conditionally cast it if using SSL.
That's exactly what I had in mind when I said it would be possible but ugly to
achieve both. Something like:
@SSL@ private javax.net.ssl.SSLSocketFactory factory;
public static void setSSLSocketFactory(Object factoryObj)
{
@SSL@ this.factory = (javax.net.ssl.SSLSocketFactory) factoryObj;
}
So you could still call setSSLSocketFactory even for a driver without SSL
compiled under JDK 1.1; but it wouldn't do anything. Alternatively, perhaps
it should throw an exception. I hate the idea of silently failing at
anything.
> One way around this would be to make the API something
> like setSSLSocketFactory(String factoryName, Object factory) and then
> have the url parameter be ?ssl=<factoryName>.
Sounds somewhat reasonable, but it does complicate the interface for the
common case. If, instead, you had methods either to set the default factory
*or* use named factories, it wouldn't force anyone to figure out an
interaction between some String parameter and a piece of the connection URL.
I doubt most applications make connections to more than one backend anyway.
> This still doesn't
> solve the problem of trying to use something like this in a
> Datasource [...]
Didn't look into that, though I agree we should definitely worry about
DataSource support... especially with Sun floating around comments like "we
expect that DriverManager will be deprecated in a future JDBC release".
> Finally I'd like to take a closer look at the other ssl options that
> are available before I committed to an API that might not support
> them. I know the server can optionally authenticate the client's
> cert and there are some other undocumented ssl things.
Sure. There are options on SSLSocket as well that this doesn't provide access
to. I can't think of a clean way to provide those options, except as yet more
separate parameters on top of this. I can't imagine asking user code to hand
us back an SSLSocket instance.
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
From | Date | Subject | |
---|---|---|---|
Next Message | Guido Fiala | 2004-02-19 16:25:32 | ResultSetMetaData.isNullable(i) not working? |
Previous Message | Kris Jurka | 2004-02-18 23:50:44 | Re: PATH: SSL flexibility and documentation |