<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 4/25/14 12:18 PM, Rod Widdowson
      wrote:<br>
    </div>
    <blockquote
      cite="mid:00bd01cf60a1$f8d31d20$ea795760$@steadingsoftware.com"
      type="cite">
      <pre wrap="">

•  Thus it becomes acceptable for
ProfileConfiguration#getSecurityConfiguration() to return null meaning “use
the default”.
</pre>
    </blockquote>
    <br>
    Yes, although it's perhaps more relevant to say that it's (also)
    acceptable for any (non-null) SecurityConfiguration returned by that
    call to return null on any of the 4 get*Configuration() methods. 
    It's not required that, if someone does define a profile
    SecurityConfiguration bean, that they have to define all 4 of the
    security -Configuration instances in it.  (And of course any of the
    properties of those -Configuration) instances may also be null, or
    empty for the collections).<br>
    <br>
    <br>
    <br>
    <blockquote
      cite="mid:00bd01cf60a1$f8d31d20$ea795760$@steadingsoftware.com"
      type="cite">
      <pre wrap="">
•  The defaultSigning key will be used to set up a SecuirtyConfiguration
with *only* a SignatureSigningConfiguration set in it.  This
SignatureSigningConfiguration will *only* have the credential set.  The rest
of the code knows/will know how to handle defaults from further on down.</pre>
    </blockquote>
    <br>
    Yes.<br>
    <br>
    There is the (slightly non-sensical but possible) case where there
    is both a non-null legacy signing credential ref AND a
    non-null/non-empty:<br>
    <br>
    ProfileConfiguration#getSecurityConfiguration()#getSignatureSigningConfiguration()#getSigningCredentials()
    <br>
    <br>
    (non-sensical b/c there's really no point in explicitly defining
    both).  <br>
    <br>
    But if that were the case... You'd probably want to munge the
    List&lt;Credential&gt; returned there to include the legacy
    Credential ref at the head of the list.  That list itself is
    immutable, so you'd have to construct a new list based off of the
    ref and the immutable list, and set that back in via the
    BasicSignatureSigningConfiguration's setSigningCredentials(...), or
    whatever.<br>
    <br>
    Or not, and we could just declare that you can't have both.  <br>
    <br>
  </body>
</html>