> > Are there any plans to make things more abstract, > > No. > > > i.e. the possibility to inject a > > ByteChannel (or NioChannel / SecureNioChannel) into the EndPoint > > implementation or is it a design goal to use SSLContext + SSLEngine > > directly in NioEndpoint? > > The extension point for SSL implementations has always been the JSSE > interface. I don't see that changing.
We are providing a custom SSLImplementation, which provides SSLSupport and ServerSocketFactory. That was straight forward. The server sockets are already based on server socket channels, so a "getChannel()" on the socket delivers an appropriate, TLS-capable channel. Tomcat 7 introduces SSLUtil with createSSLContext, getKeyManagers, getTrustManager and configureSessionContext shifting complexity into the Tomcat core and creating a noteworthy overhead in the SSL stack to expose low-level and proprietary (no JSR) javax.net.ssl.* classes beyond SSLServerSocket and SSLSession. > If you have changes you would like to suggest that: > a) make your own extension simpler > b) are minimal impact on the existing code and user base > > then they'd certainly be considered. NioEndpoint could use a ChannelProvider to retrieve NioChannel / SecureNioChannel. The DefaultChannelProvider would be equivalent to the code in NioEndpoint.setSocketOptions(). A SSLImplementation or SSLUtil class should provide a decorator-pattern method returning a NioChannel for a SocketChannel argument. That makes NioEndpoint more abstract, focused to its core functionality and shifts all the SSL engine handling overhead out to either a dedicated default provider or a highly specialized, custom TLSChannel. Reasons for this are among other things the SSL-session clustering capabilities and transparent session resuming on disconnect / node- error. Best regards, Christian --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
