[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

2016-05-21 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295211#comment-15295211
 ] 

ASF subversion and git services commented on SOLR-8970:
---

Commit 3cc008253513977d1554de3be1c34f35bc4461ae in lucene-solr's branch 
refs/heads/branch_6_0 from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3cc0082 ]

SOLR-8970: Change SSLTestConfig to use a keystore file that is included as a 
resource in the test-framework jar so users subclassing SolrTestCaseJ4 don't 
need to preserve magic paths

(cherry picked from commit 76063648ae05a935459f2ea5ed53c4df1caa713d)


> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.0.1, 6.1, master (7.0)
>
> Attachments: SOLR-8970.patch, SOLR-8970.patch, SOLR-8970.patch
>
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

2016-05-21 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295091#comment-15295091
 ] 

ASF subversion and git services commented on SOLR-8970:
---

Commit 4031d3fd469a7df58bc5642c7a3caec01aa6b23c in lucene-solr's branch 
refs/heads/branch_6_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4031d3f ]

Revert "SOLR-8970: Change SSLTestConfig to use a keystore file that is included 
as a resource in the test-framework jar so users subclassing SolrTestCaseJ4 
don't need to preserve magic paths"

This reverts commit 124301d69812e4b9a83c440c70736c6d301baf44.


> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.0.1, 6.1, master (7.0)
>
> Attachments: SOLR-8970.patch, SOLR-8970.patch, SOLR-8970.patch
>
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

2016-05-20 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15294398#comment-15294398
 ] 

ASF subversion and git services commented on SOLR-8970:
---

Commit c105675a90134b75d00cf109d5ae4383e44c09d0 in lucene-solr's branch 
refs/heads/branch_6_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c105675 ]

SOLR-8970: branch_6_0: move CHANGES entry from 'Other Changes' section to 'Bug 
fixes'


> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.0.1, 6.1, master (7.0)
>
> Attachments: SOLR-8970.patch, SOLR-8970.patch, SOLR-8970.patch
>
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

2016-05-20 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15294386#comment-15294386
 ] 

ASF subversion and git services commented on SOLR-8970:
---

Commit 124301d69812e4b9a83c440c70736c6d301baf44 in lucene-solr's branch 
refs/heads/branch_6_0 from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=124301d ]

SOLR-8970: Change SSLTestConfig to use a keystore file that is included as a 
resource in the test-framework jar so users subclassing SolrTestCaseJ4 don't 
need to preserve magic paths

(cherry picked from commit 76063648ae05a935459f2ea5ed53c4df1caa713d)


> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.0.1, 6.1, master (7.0)
>
> Attachments: SOLR-8970.patch, SOLR-8970.patch, SOLR-8970.patch
>
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

2016-05-20 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15294387#comment-15294387
 ] 

ASF subversion and git services commented on SOLR-8970:
---

Commit f6117793024c626cf0b07f390112cdec99de4847 in lucene-solr's branch 
refs/heads/branch_6_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f611779 ]

SOLR-8970: IntelliJ config: add src/resources/ as a java-resource dir to the 
solr-test-framework module, so that resources there get copied into the 
compilation output dir.


> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.0.1, 6.1, master (7.0)
>
> Attachments: SOLR-8970.patch, SOLR-8970.patch, SOLR-8970.patch
>
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

2016-05-17 Thread Steve Rowe (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15286973#comment-15286973
 ] 

Steve Rowe commented on SOLR-8970:
--

Manually adding info here for the branch_6x commit I did for the IntelliJ 
fixes, which for some reason didn't get autocommented here - from the commit 
email to commits@l.a.o:

Repository: lucene-solr
Updated Branches:
 refs/heads/branch_6x f73997bb4 -> 29e7d64da

SOLR-8970: IntelliJ config: add src/resources/ as a java-resource dir to the 
solr-test-framework module, so that resources there get copied into the 
compilation output dir.

Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/29e7d64d
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/29e7d64d
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/29e7d64d

Branch: refs/heads/branch_6x
Commit: 29e7d64da14a78bf8f1173a01d1553f69a27e9c7
Parents: f73997b
Author: Steve Rowe 
Authored: Mon May 16 20:55:32 2016 -0400
Committer: Steve Rowe 
Committed: Mon May 16 20:56:15 2016 -0400


> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8970.patch, SOLR-8970.patch, SOLR-8970.patch
>
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

2016-05-16 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15285763#comment-15285763
 ] 

ASF subversion and git services commented on SOLR-8970:
---

Commit 6942fe2d202a0345c4baf1b6292be7d8d5fd2f9e in lucene-solr's branch 
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6942fe2 ]

SOLR-8970: IntelliJ config: add src/resources/ as a java-resource dir to the 
solr-test-framework module, so that resources there get copied into the 
compilation output dir.


> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8970.patch, SOLR-8970.patch, SOLR-8970.patch
>
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

2016-04-29 Thread Joseph Lawson (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15265044#comment-15265044
 ] 

Joseph Lawson commented on SOLR-8970:
-

Thanks for sticking with this.

> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8970.patch, SOLR-8970.patch
>
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

2016-04-12 Thread Joseph Lawson (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15237180#comment-15237180
 ] 

Joseph Lawson commented on SOLR-8970:
-

Also this affects 6.0

> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

2016-04-11 Thread Joseph Lawson (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236384#comment-15236384
 ] 

Joseph Lawson commented on SOLR-8970:
-

It would be nice if the keystore blob was included in the test jar so that 
reusing SolrTestCaseJ4 in projects wouldn't require much setup beyond extending 
or just using the class. Letting it be overridden via sysprops is good too.

> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

2016-04-11 Thread Hoss Man (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236345#comment-15236345
 ] 

Hoss Man commented on SOLR-8970:


as things stand now, combined with SOLR-8971, this problem manifests itself in 
user tests in the most obtuse way possible...

{noformat}
Date: Mon, 11 Apr 2016 12:29:42 -0400
From: Joe Lawson
Subject: Solr 6 - AbstractSolrTestCase Error Unable to build KeyStore from 
file: null

I'm upgrading a plugin and use the AbstractSolrTestCase for tests. My tests
work fine in 5.X but when I upgraded to 6.X the tests sometimes throw an
error during initialization. Basically it says,
"org.apache.solr.common.SolrException: Error instantiating
shardHandlerFactory class
[org.apache.solr.handler.component.HttpShardHandlerFactory]: Unable to
build KeyStore from file: null"

...

> NOTE: reproduce with: ant test  -Dtestcase=TestConstructedPhrases
>> -Dtests.seed=48D5F3D29EAB417 -Dtests.locale=en
>> -Dtests.timezone=America/Blanc-Sablon -Dtests.asserts=true
>> -Dtests.file.encoding=UTF-8
>
>
>> org.apache.solr.common.SolrException: Error instantiating
>> shardHandlerFactory class
>> [org.apache.solr.handler.component.HttpShardHandlerFactory]: Unable to
>> build KeyStore from file: null
>
>
>> at __randomizedtesting.SeedInfo.seed([48D5F3D29EAB417]:0)
>
> at
>> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:52)
>
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:404)
>
> at org.apache.solr.util.TestHarness.(TestHarness.java:164)
>
> at org.apache.solr.util.TestHarness.(TestHarness.java:127)
>
> at org.apache.solr.util.TestHarness.(TestHarness.java:133)
>
> at org.apache.solr.util.TestHarness.(TestHarness.java:96)
>
> at org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:598)
>
> at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:588)
>
> at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:430)
>
> at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:419)
>
> at
>> org.apache.solr.search.HonLuceneSynonymTestCase.beforeClass(HonLuceneSynonymTestCase.java:36)
{noformat}

> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8970) SSLTestConfig behaves really stupid if keystore can't be found

2016-04-11 Thread Hoss Man (JIRA) 

[ 
https://issues.apache.org/jira/browse/SOLR-8970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236338#comment-15236338
 ] 

Hoss Man commented on SOLR-8970:


SSLTestConfig already sanity checks whether TEST_KEYSTORE exists...
{code}
  public static File TEST_KEYSTORE = ExternalPaths.SERVER_HOME == null ? null
  : new File(ExternalPaths.SERVER_HOME, "../etc/test/solrtest.keystore");  
  private static String TEST_KEYSTORE_PATH = TEST_KEYSTORE != null
  && TEST_KEYSTORE.exists() ? TEST_KEYSTORE.getAbsolutePath() : null;
{code}

We should...

* change how TEST_KEYSTORE_PATH is initialized so that people using 
SolrTestCaseJ4/SSLTestConfig can set a sysprop when running tests to change 
which path to use when looking for the file
* change SSLTestConfig's constructors so that if {{clientAuth==true}} but 
{{TEST_KEYSTORE_PATH==null}} (either because the TEST_KEYSTORE file does not 
exist and no sysprop was used to override it) then we fail fast with a useful 
error telling people to either:
** set the test sysprop
** ensure the expected file is in TEST_KEYSTORE
** add {{@SupressSSL}} to their tests.

> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org