Ulrich Meis wrote:
> On Tuesday 12 October 2004 04:57, Oliver Jowett wrote:
>
>
>>So I suggest you look at solving the "how do I give the driver an
>>appropriate SSLSocketFactory" problem first. Once that is solved, the
>>particular configurable behaviour you want can be easily implemented.
>
>
> How about my suggestions with the abstract handler class?
> I know it was a long post ;-)
Namely:
> In the Driver class you offer a method(make it empty if compiled without SSL):
>
> setPGSSLHandler(PGSSLHandler handler) {
> pgsslhandler=handler;}
>
> abstract class PGSSLHandler {
>
> public static final int STANDARD=0;
> public static final int CUSTOMFACTORY=1;
> public static final int CUSTOMSTORE=2;
>
> abstract public int getHandleType(int conid);
> abstract public boolean getTrustAndSave(int conid);
>
> abstract public KeyStore getKeyStore(int conid);
> abstract public SSLSocketFactory getSSLSocketFactory(int conid);
>
> }
How do you arrange for setPGSSLHandler to be called if you are in a
managed environment that does not know anything about the postgresql
driver beyond the standard JDBC interfaces?
The "conid" stuff looks really grotty. How do you coordinate the
URL-level configuration with the PGSSLHandler implementation?
Why is anything but getSSLSocketFactory() needed? You can implement
whatever keystore/truststore policy you want via a SSLSocketFactory.
The only new thing there is really the conid stuff, and I'd rather deal
with classloader issues (specify the class by name, loaded by the
driver) than have to deal with managing magic opaque unique
configuration keys and a postgresql-specific interface.
-O
