[
https://issues.apache.org/jira/browse/SOLR-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289889#comment-15289889
]
Steve Rowe commented on SOLR-9107:
----------------------------------
+1 overall, all Solr tests passed for me on Linux and OS X (modulo a couple
that fail intermittently without this patch too).
On SSL usage probabilities: nice folding in of tests.nightly (though the ~10%
greater likelihood in your patch seems a little low) and tests.multiplier
(taking the log means the default multiplier of 1 won't change the declared
odds, since ln(1)=0).
-----
Since the method below is only ever called from SolrTestCaseJ4.beforeClass(),
and all SolrTestCaseJ4 subclasses will inherit its @RandomizeSSL (or override
it with their own), {{annotation}} in the code below will never be null, I
think? I guess this handles the case of third-party usage when not extending
SolrTestCaseJ4?
{code:java|title=From RandomizeSSL.getSSLRandomizerForClass(Class)}
if (null == annotation) {
return new SSLRandomizer(0.0D, 0.0D, RandomizeSSL.class.getName() + "
annotation not specified");
}
{code}
I see TestSSLRandomization.testSSLRandomizer() mostly tests classes that don't
inherit from an annotated class, but that's zero actual Solr test cases, right?
I think more testing of the inheriting cases is warranted.
-----
{code:java|title=From RandomizeSSL.getSSLRandomizerForClass(Class):}
// nocommit: WTF won't this compile w/o casting???
//final RandomizeSSL annotation = clazz.getAnnotation(RandomizeSSL.class);
final RandomizeSSL annotation = (RandomizeSSL)
clazz.getAnnotation(RandomizeSSL.class);
{code}
Type erasure is a runtime thing, so I'm not sure why the compiler doesn't like
it.
The following works, and is maybe a clue about what's happening, but isn't
really better than casting (from one of the answers here:
[http://stackoverflow.com/questions/450807/how-do-i-make-the-method-return-type-generic]):
{code:java}
final RandomizeSSL annotation =
clazz.<RandomizeSSL>getAnnotation(RandomizeSSL.class);
{code}
> 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
>
>
> 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]
