This content has been marked as final. Show 4 replies
After that discussion I don't know why you're doing this at all, but from the source code, quoted without permission:
* The new X509 key manager implementation. The main differences to the * old SunX509 key manager are: * . it is based around the KeyStore.Builder API. This allows it to use * other forms of KeyStore protection or password input (e.g. a * CallbackHandler) or to have keys within one KeyStore protected by * different keys. * . it can use multiple KeyStores at the same time. * . it is explicitly designed to accomodate KeyStores that change over * the lifetime of the process. * . it makes an effort to choose the key that matches best, i.e. one that * is not expired and has the appropriate certificate extensions. * ... // a unique id is included to allow us to reliably cache entries // between the calls to getCertificateChain() and getPrivateKey() // even if tokens are inserted or removed
I wouldn't expect you to understand why I need (or needed) to do this, as you don't know about the projects I'm working on.
I wish there is another way to achieve it, though :(. Caching is an implementation detail and shouldn't affect the way the public interface works, in my opinion. The client aliases do not have numbers on them.
Imagine if database vendors messed with your data to implement indexes or constraints :/...
"What's your name?"
"That's a funny name..."
"Yeah, they used WeirdDB back then."
By the way. I just downloaded the jdk source code. I hope I can contribute in some way.
Edited by: daniel.mfreitas on May 28, 2009 7:44 AM
Why don't you just use the "SunX509" implementation? It may be true the "NewSunX509" implementation has some features that are not documented as well as they should be, but you had to expect something different when you tried "New" and you figured it out for yourself anyway.
I actually don't even need to use this approach anymore as we now keep only one certificate in the keystore. Now it's just a matter of learning a little bit more about the API. In the future we might need to have multiple certificates in a keystore and have to select a specific one.
It would be good if we could make caching work and still leave the alias (at least the ones obtained from the public api) untouched. By quickly looking at the code I didn't see much relation between the map where they keep the cache and the getClientAliases() method. getClientAliases() does not even look at the cache (but it seems it stores values in the cache, I might be mistaken though). Instead, the method transforms all aliases by prefixing the numbers before returning from the method call.
I'm not getting the whole picture yet. I think I will debug inside the code to see how it works and ask around to see in which scenario the cached aliases would make the difference.
Thanks for all the input. I will post my findings if I ever get there for the sake of documenting it for other who might be interested.