(though the ~10% greater likelihood in your patch seems a little low)
I'm trying to keep things a bit conservative for now ... i don't want to cause the runtime of jenkins nightly builds to explode. It can always be increased later.
... I guess this handles the case of third-party usage when not extending SolrTestCaseJ4?
yeah, i'm mainly just trying to be paranoid here – like "what if someone (solr committer or third party dev) writes a new test baseclass that doesn't subclass SolrTestCaseJ4 and tries to use getSSLRandomizerForClass w/o realizing it's only for classes w/that annotation?" or "what if we decide not all tests should use SSL implicitly and remove the anotation from SolrTestCaseJ4 in the future?"
I see TestSSLRandomization.testSSLRandomizer() ... I think more testing of the inheriting cases is warranted.
The following works, ...
Not for me it didn't...
[javac] /home/hossman/lucene/dev/solr/test-framework/src/java/org/apache/solr/util/RandomizeSSL.java:153: error: incompatible types: Annotation cannot be converted to RandomizeSSL
[javac] final RandomizeSSL annotation = clazz.<RandomizeSSL>getAnnotation(RandomizeSSL.class);
...but like you said, not really any cleaner then casting, and i don't really care enough to waste more time on figuring out why it doesn't work.
- fixes the last few nocommits (SuppressSSL now reports the bugUrl in the logs)
- improves testing of the various inheritence situations
- add a comment clarifying to future devs readng the code why an inherited SuppressSSL should override a direct RandomzeSSL annotation.
- at some multiplier randomization to the "always" and "never ever" checks in testSSLRandomizerEffectiveOdds to ensure we always do the right thing no matter how crazy the test runner might be
I'm pretty happy with how things are, and would like to commit soon – but as things stand with this patch, precommit currently complains about malformed javadocs...
[echo] Checking for malformed docs...
[exec] broken details HTML: Field Detail: reason: saw closing "</ul>" without opening <ul...>
[exec] broken details HTML: Field Detail: ssl: saw closing "</ul>" without opening <ul...>
[exec] broken details HTML: Field Detail: clientAuth: saw closing "</ul>" without opening <ul...>
...but i can't really understand why. The <ul> tags look balanced to me, and tidy -output /dev/null .../RandomizeSSL.html concurs that "No warnings or errors were found." I thought maybe the problem was related to some of the @see tags in the docs for these attributes, but even if i completley remove the javadocs the same validation errors occur.
Anybody have any idea what's going on here? Steve Rowe? Uwe Schindler?