[
https://issues.apache.org/jira/browse/SOLR-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15314110#comment-15314110
]
Hoss Man edited comment on SOLR-9107 at 6/3/16 6:10 PM:
--------------------------------------------------------
EDIT: Typo Commit Msg for SOLR-9081
was (Author: jira-bot):
Commit aed3fc11b18c75ec23416579276dc70c87103c37 in lucene-solr's branch
refs/heads/master from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=aed3fc1 ]
SOLR-9107: Make SolrTestCaseJ4.beforeClass() / .afterClass() public
> 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]
