Filip Hanik - Dev Lists wrote:
Bill Barker wrote:
I'm for removing support for PureTLS, since it is largely unmaintained
at the moment. But the abstraction is usefull to be able to support
SSL providers (e.g. Mozilla meantioned above) that don't implement
JSSE. It wasn't about getting removing it from the NIO Connecter,
just making the signature not depend on JSSE. So for JSSE, something
like:
public SSLSupport getNioSSLSupport(Socket sock) {
return factory.getSSLSupport(((SSLSocket)sock).getSession());
}
I guess what I'm confused about is the signature change and the name of
the method.
With NIO there is no such thing as an SSLSocket, but the method name
indicates that the method is used only for NIO.
With NIO you have access to the SSLSession, through the SSLEngine. The
concept of SSLSocket doesn't exist, since the encryption/decryption
happens outside of the realm of sockets.
There appears to be general agreement on removing the TLS stuff. I'll get
that done.
Re the abstraction, I have done some background reading and our current
socket based SSL abstraction just won't work for NIO.
Option 1 is to provide an NIO compatible transport independent SSL
abstraction, an implementation of the abstraction using JSSE and re-write
the NIO (and possibly the BIO) connector to use it. However, this would be
a lot of work for little gain.
Given that the NIO connector is hard coded to use JSSE anyway, options 2 is
to modify the NIO connector to go straight to the JSSE implementation,
bypassing the abstraction. That would enable the JSSE specific code to be
removed from the abstraction, allowing other non-JSSE socket based SSL
implementations for the BIO connector should anyone feel so inclined. At a
later point if someone has an itch to implement option 1 then there would
be nothing stopping them.
I'll start working up a patch - it should be simple. Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
