-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 9/12/18 17:20, Mark Thomas wrote: > 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. Fair enough, but it's quite rare that OpenSSL announces a new release line (at all) and then it takes some time before that line is adopted and distributed to anyone but very bleeding-edge shops. I think any lag between a release and Tomcat building automated tests against it would be short enough to not present any problems. >> 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 ;) :) We need some C programmers to build a bunch of unit tests for tcnative. That would be another great GSoC project, though not very sexy . >> (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. The only thing I can think of is to create a new annotation for unit tests like ConnectorAgnostic or something to that effect. Then, they could be skipped after being run once (on any connector type). I think that would require JUnit to be complicit with any such scheme, and I'm not sure how to do that. Another option would be to have those connector-agnostic unit tests in a separate set of packages, and then run those separately a single time and the connector-based unit tests per-connector. Lots of re-organization for minimal gain. Well, time spent running unit tests, but I don't know about everyone else, bu I just do a "nohup ant test > tomcat_version.log &" and let it run as long as it needs to run. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluepxcACgkQHPApP6U8 pFjSkA/+KN9Ct2Btilfxaw3unYmeLpwflAasYqrdfqTxN9idHP/NcbRtb9IHmdpu PuNpMaLv+Gfsdn5dejPDjNFaEAnsNNGdJ3yD0sI0HIRXujnJvC7vWlGT5ZDDQbU/ zNei9c+tS8NOkljXtb7qy/MQ42UHhxa33Z6gTaKEOf7N+QRMP38LTK4xF8BgjUEW klLS+gWgcjBaNv88KiWWkVjNq7/Ugvb+9o6cTtIJsKca7AAE4KdoAX0neR/Wz9uT KY+rVztMsgq2Sz8qPbZ0Rpn4hHC1mOj0WeSg07a51cIv1TCLqSBwb2D4gupMI3ZN yhMWL0X8zORfD7TDB7Q1+p2NGdlBs5WqCOygliALTAKYKe2sMUdAOITt9fkh22eT DnG4MtEQefLtczL0n4cC5n9zbFAos9N/BzR574Q9Gp9/hBi34Mooh2VT+o6dzWQD ACKUUA840swnX9Hqsv9PP5wbaT4uJ6UdCv66RthTXl6SpiiCIWuQakjisSYao4sA qdzje1RQqrzMl9zqtp5XADEsAKUg2S484vvzNoVifKiJS9sDXwdqp0bmk+goJfYp qV9Ul4NcVmiKX5zZNwiHF2pFeOsWFVUr5zvWgnRGque3kySSfiFpq/PQtznGu2PJ d3MEuTyvTEGf+HXazYaT1pzXuIqaq3Ef2lPuPKEB49UK0toXiYM= =Hl4l -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
