Thank you for the prompt response. With all due respect, I would disagree. And the proof is in 2 places:
1. By default the code creates a JettySslFactoryConnector. Calling createConnector() on the factory returns an instance of CXFJettySslSocketConnector which extends SslSelectChannelConnector. This is great but there is no way for me to configure the number of acceptors on that channel. Maybe that is an enhancement request. Either way clearly there was intent to support this. 2. Look at the else statement of that method which is called when you specify a connector for a plain HTTP engine. The error checking in the code has a big problem: it only throws an error if the connector is of type SslSocketConnector (since it is plain HTTP not HTTPS you can't use that connector). That means that I could specify a connector of type SslSelectChannelConnector for a plain HTTP engine and it would not report that as a problem. That's obviously not right. In my humble opinion, what the code should do is check that the set connector implements the SslConnector interface. Both SslSocketConnector and SslSelectChannelConnector implement the SslConnector interface. This would result in correct behavior when setting an SSL connector and correct error checking when not. My guess is that this was probably a typo. It's a simple change and I would even be happy to make it. Once again I just need a little hand holding to do it. -- View this message in context: http://cxf.547215.n5.nabble.com/Bug-in-2-7-2-tp5722635p5722733.html Sent from the cxf-user mailing list archive at Nabble.com.
