Hi Mark,

Enhancing the CommunicationsException didn't really help. I increasingly get the feeling that com.mysql.jdbc.ExportControlled.transformSocketToSSLSocket(MysqlIO mysqlIO) might deserve some re-engineering to allow for thread-safe SSL use.

Assume the following hypothetical setting:

An application jdbc-connects to more than 1 different data sources at different institutions each mandating their own set of acceptable SSL ciphers, thus requiring different SSL-factories.

So, it appears that 1) javax.net.ssl.SSLSocketFactory.getDefault() ONLY ONCE consults the java.security.Security.getProperty("ssl.SocketFactory.provider") which thereafter is a private static global setting no longer changeable by the application. 2) furthermore, due to AccessController.doPrivileged(... , it has restrictive rules which SSLSocketFactoryImplementations it allows for. If it does not like your factory, it will resort to the non-functional javax.net.ssl.DefaultSSLSocketFactory without providing further insights why it refuses :(

In similar contexts, it appears that even Sun itself was not comfortable with this inflexible architecture.

Therefore I suggest to have a look at javamail's com.sun.mail.util.SocketFetcher.getSocket0(String host, int port, Properties props, String prefix, boolean useSSL) for inspiration how to make this more versatile.

What do you think?

Ralf