SOLR-9040 helped me discover some stuff about when/how exactly the JVM reads in the javax.net.ssl.* sys props to build the default SSLContext – notably: it's a singleton, so we can't change the sysprops after startup and expect it to do what is expected. (And there doesn't appear to be ably convinience classes/methods for loading a "custom" SSLContext that obeys those properties by default unless/until you override them)
In this updated patch, I've added test code to preserve the SSLContext.getDefault() on test class init, and use SSLContext.setDefaul() during testing to mimic the effects of how the JVM should behave if the corisponding javax.net.ssl.* properties had been set. (then restore the preserved default in an @After method)
This seems to be working well.
I briefly considered eliminating all of the explicit modifications of HttpCiientUtil's HttpClientBuilder / SchemaRegistryProvider in these tests, so we were always mimicing how a solrj code will behave by default when these props are set, but ultimately I think the current mix of both styles of getting an SSLContext are better – it helps us test both the "solrj client expects to use standard javax sys properties" approach, and the "solrj client code explicitly using HttpCiientUtil to say 'use these options for ssl'" approach.
There's still a handful of nocommits, that fall into two categories:
- I want to cleanup some of the SSLTestConfig methods that only exist in master and have weird side effects (introduced in
- I think it might makes sense to promote the the SSLContext.getDefault/setDefault preservation to SolrTestCaseJ4 ... but i'm not 100% certain yet. Need to think it through more.