Kris Jurka wrote:
> On Mon, 2004-09-13 at 07:47, chinmoy wrote:
>
>>Hi
>> Thanks for the reply. The only thing special about the factory is
>>that it has access to the server certificate that is bundled with the
>>client jars and is not installed in the jvm's trust store. I agree the
>>static method is not the way to go as it affects all the connections. In
>>my specific case it is okay as I know all the clients using the
>>connections in agiven client jvm.
>
>
> What about an additional URL parameter like
> sslfactoryfactory=com.mycompany.myfactory, where the provided class must
> implement something like:
>
> package org.postgresql;
>
> interface SSLSocketFactoryFactory {
> public SSLSocketFactory getFactory();
> }
>
> Seems like this could work. Thoughts? Any other SSL options and things
> people would want to tweak?
I'm not sure how that extra level of indirection gives you anything.
Haven't you just gone from "how do I configure my new SSLSocketFactory
instance without context?" to "how do I configure my new
SSLSocketFactoryFactory instance without context?" ?
If we want per-connection SSL configurability (not just per-JVM) then it
seems like we have to pass an actual instance to the driver at runtime.
URL parameters aren't going to do the job unless we also pass
factory-specific configuration info in the URL somehow, and that assumes
that you can actually represent that info in the URL (e.g. you have more
than just an object reference to your keystore..)
I also dislike having the driver do any classloading of client classes
itself. It causes havoc in a managed environment where the JDBC driver
may be loaded in its own classloader that does not have access to the
application classes. I added the new variant of PGConnection.addDataType
to solve exactly this problem; let's not reintroduce it elsewhere.
-O