Setting fields using System.setProperty(...) is nasty as it's a global variable by any other name. But sometimes you have to tolerate it when dealing with other people's libraries.
One such library is Java's security classes where you can define your key store file by setting system property javax.net.ssl.keyStore. But be warned: you can only use it once. After that, it is set for the lifetime of the JVM.
If you take a peek into DefaultSSLContextImpl.getDefaultKeyManager(...), you'll see the static defaultKeyManagers being set (from a KeyManagerFactory initiated with a KeyStore that was loaded from the file in the system property). Subsequent calls to this method get the static reference.
This monkeyed around with our test suite no end as it was not immediately obviously where this was being set.
As it happened, an earlier test set it incorrectly but didn't exercise that path of the code. Later in the suite, we saw NoSuchAlgorithmException being thrown by an unrelated test. This is a misleading error.
"NoSuchAlgorithmExceptions are often cause by other underlying exceptions (file not found, wrong password, wrong keystore type, ...)." - from Bruno on StackOverflow.
And so it proved to be. The path the key store value was pointing to didn't exist.
[Miscellaneous: pictures of the SSL Handshake and the Wikipedia description are worth seeing.]
One such library is Java's security classes where you can define your key store file by setting system property javax.net.ssl.keyStore. But be warned: you can only use it once. After that, it is set for the lifetime of the JVM.
If you take a peek into DefaultSSLContextImpl.getDefaultKeyManager(...), you'll see the static defaultKeyManagers being set (from a KeyManagerFactory initiated with a KeyStore that was loaded from the file in the system property). Subsequent calls to this method get the static reference.
This monkeyed around with our test suite no end as it was not immediately obviously where this was being set.
As it happened, an earlier test set it incorrectly but didn't exercise that path of the code. Later in the suite, we saw NoSuchAlgorithmException being thrown by an unrelated test. This is a misleading error.
"NoSuchAlgorithmExceptions are often cause by other underlying exceptions (file not found, wrong password, wrong keystore type, ...)." - from Bruno on StackOverflow.
And so it proved to be. The path the key store value was pointing to didn't exist.
[Miscellaneous: pictures of the SSL Handshake and the Wikipedia description are worth seeing.]
