[
https://issues.apache.org/jira/browse/SOLR-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-9107:
---------------------------
Attachment: SOLR-9107.patch
bq. (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.
bq. ... 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?"
bq. I see TestSSLRandomization.testSSLRandomizer() ... I think more testing of
the inheriting cases is warranted.
Good point.
bq. The following works, ...
Not for me it didn't...
{noformat}
[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);
{noformat}
...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.
----
Updated patch:
* 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...
{noformat}
[echo] Checking for malformed docs...
[exec]
[exec]
/home/hossman/lucene/dev/solr/build/docs/solr-test-framework/org/apache/solr/util/RandomizeSSL.html
[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...>
{noformat}
...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]? [~thetaphi]?
> add annotation for more fine grained control of SSL per test-class
> ------------------------------------------------------------------
>
> Key: SOLR-9107
> URL: https://issues.apache.org/jira/browse/SOLR-9107
> Project: Solr
> Issue Type: Sub-task
> Reporter: Hoss Man
> Fix For: 4.9, 6.0
>
> Attachments: SOLR-9107.patch, SOLR-9107.patch
>
>
> Spinning off this idea from my earlier comment in SOLR-5776...
> ----
> At some point in the future, after all this soaks, we should consider
> increasing the odds of using SSL – perhaps even add a new annotation (or
> replace @SupressSSL) with a param to help control the odds of using SSL /
> clientAuth on a per-class basis, ie...
> {noformat}
> @UseSSL(false) // same as @SupressSSL
> @UseSSL() // same as default if no annotation: SolrTestCaseJ4 picks SSL /
> clientAuth using LuceneTestCase.rarely
> @UseSSL(ssl=0.75,clientAuth=0.25) // fine control of odds of using ssl &
> clientauth
> {noformat}
> ...some tests, like TestSSLRandomization should ideally have much higher odds
> of using SSL then other tests, and if we had an easy way to say "these
> handful of simple cloud tests should use SSL very frequently" then it
> wouldn't matter so much if the odds of other really 'expensive' tests only
> use SSL once in a blue moon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
