On 12/09/18 17:25, Christopher Schultz wrote: > Mark, > On 9/12/18 7:12 AM, Mark Thomas wrote:
<snip/> >> Testing all 12 combinations (4 OpenSSL * 3 Tomcat) seems like >> overkill. > > I would propose building+testing against both 1.0.2 (LTS) and 1.1.1 > (LTS) but leaving 1.1.0 and master out of the automated builds. > Certainly, both 1.1.0 and master should be testable, but I don't think > automated testing should be necessary. Testing with master has given us a heads up when OpenSSL adds new ciphers and/or disables old ciphers so we can update what is effectively our port of the OpenSSL cipher configuration string parsing code and ensure that - as far as we can - we keep out code consistent with OpenSSL. > Ideally, Tomcat itself should not need testing with tcnative *at all*. Ideally, I agree. But the two are tightly coupled so that would be hard to achieve. Maybe with Native 2.0... > The testing of tcnative *itself* should be able to determine whether > various combinations of tcnative+OpenSSL x.y.z will work together. A > smoke-test that tcnative continues to work with both the APR and > NIO/NIO2 connectors should be sufficient in most cases. This may not > be possible given our current set of unit tests for tcnative. The current unit tests are, um, 'minimal' (and imported from Tomcat) so I'd have to say "may not be possible" is putting a very positive spin on it ;) > (I'm always irritated whenever every. Single. Unit. Test. must be run > against all connector types even when the connector-type should have > zero impact on the test.) I hear you. No solution jumps to mind. Any ideas? I tend to lean more towards trying to speed up start/stop as a way to reduce the test time as we do that so many times. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
