<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 5/27/14 7:33 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CFAA96E4.D91E%25cantor.2@osu.edu" type="cite">
<blockquote type="cite">
<pre wrap="">However, since KeyInfo is optional, it might be prudent to actually
configure in a ChainingCredentialResolver, with a Collection- one as the
first member and a Static- one as the second. That way you get KeyInfo
hint optimization, but also fall back to trying all local creds if
hinting doesn't work or doesn't resolve anything.
</pre>
</blockquote>
<pre wrap="">
Ok, that's why I'm concerned about hiding a lot of this, it's too detailed
for a user.
</pre>
</blockquote>
<br>
Actually, I just realized that doing the chaining that way will
cause duplicates, and therefore unnecessary processing, due to the
static resolver being called potentially many times (once for each
PublicKey and key name seen from the resolved KeyInfo). What I
think we actually want is: the KeyInfoCredentialResolver wired into
the DecryptionConfiguration would be a chaining one: the first
member would be the LocalKeyInfo- one I was describing, and the
second a StaticKeyInfo- one. The local CredentialResolver wired to
the LocalKeyInfo- one would just then be a plain
CollectionCredentialResolver. You'd presumably just inject the same
list/set of Credentials into both the StaticKeyInfo- and Collection-
resolvers.<br>
<br>
However, I just noticed that we don't actually have a
ChainingKeyInfoCredentialResolver. I'll work on that tomorrow.
It's non-trivial code b/c of all the Iterable/Iterator stuff, in
order to do the iteration in an efficient and lazy fashion. But I
can just copy the existing ChainingCredentialResolver, or maybe see
if it can just be subclassed, with narrowing the return type.<br>
<br>
Also looks like the latter needs to be updated anyway to be more
Spring-friendly. It current uses a mutable <tt>List<CredentialResolver>
getResolverChain()</tt>, rather than setter or constructor
injection.<br>
</body>
</html>