Skip site navigation (1) Skip section navigation (2)

Re: A solution to the SSL customizing problem

From: Kris Jurka <books(at)ejurka(dot)com>
To: Ulrich Meis <kenobi(at)halifax(dot)rwth-aachen(dot)de>
Cc: Oliver Jowett <oliver(at)opencloud(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: A solution to the SSL customizing problem
Date: 2004-10-17 12:07:37
Message-ID: (view raw or whole thread)
Lists: pgsql-jdbc

On Sat, 16 Oct 2004, Ulrich Meis wrote:

> [here's a patch to customize ssl.]

I've applied a modified version of this patch.  I moved the Driver.makeSSL 
implementation into it's own class to not use @SSL@ everywhere.  I renamed 
the sslfactoryargs to sslfactorarg because it really is one argument.  If 
the user chooses to encode multiple arguments into it, that's really his 
own business.  I put a NonValidatingFactory class in to demonstrate 
how this can work and provide the most requested functionality.


In the non-validating factory I have a SSLContext.getInstance("TLS"), but 
I've also seen it use "SSL".  Is either preferred or does it matter for 

I've been building the jdbc2ee jar files against the actual j2sdkee1.2.1, 
not just the jdbc optional package.  This includes support for, but not and 
associated classes which are in instead.  So at the moment 
I've modified the ssl requirements to not build ssl into this 
particular jar.  What do we want to do about this:

 - nothing, the ee really meant datasource and was never meant to
   include ssl
 - make the existing ssl support work by not building the 
   NonValidingFactory class
 - make everything work by building the NonValidatingFactory by importing
   from instead.

Kris Jurka

In response to


pgsql-jdbc by date

Next:From: Kris JurkaDate: 2004-10-17 12:58:39
Subject: setBinaryStream can abandon connection
Previous:From: Kris JurkaDate: 2004-10-17 05:05:20
Subject: Re: Error connecting when user has no password

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group