Spring shorthand, again

[Nate Klingenstein]

> But that's what I did...so I don't understand the suggestion to change something. I considered what Daniel suggested, and we could do that, but I did it this way to basically emulate what seemed like an accepted approach elsewhere.

I think it’s elsewhere, but not everywhere.  The alternative would be to add a comment to idp.properties or ldap.properties that says basically the exact same thing that you said and the comment in sshd_config says.  I don’t think it’s anywhere now.

  1 # Load any additional property resources from a comma-delimited list
  2 idp.additionalProperties= /conf/ldap.properties, /conf/saml-nameid.properties, /conf/services.properties
  3 
  4 # Set the entityID of the IdP

...

  1 # LDAP authentication configuration, see authn/ldap-authn-config.xml
  2 # Note, this doesn't apply to the use of JAAS
  3 
  4 ## Authenticator strategy, either anonSearchAuthenticator, bindSearchAuthenticator, directAuthenticator, adAuthentic    ator
  5 #idp.authn.LDAP.authenticator

…

> There's no conflict or "hiding" of anything.

No doubt.  Thinking through where people have problems, it’s exactly the locality thing you mentioned.  Half properties, half XML, half Spring.  It all makes sense after you know what it’s doing, but it’s like we each have a little syntax switch in our heads that works in one mode or the other.

> There are some rough edges like the certificate/trust paths because of the problems defaulting those, where as boolean and numeric data can be defaulted cleanly.

The interlacing trust stuff is definitely icing, especially since it has been a syntax complaint that appears unrelated to what you just changed.

> One problem IMHO is the bad locality of reference between the properties and where they're used. The fix for that is not to use properties. And I'm not against that idea, personally. I think it works badly for certain areas of the system, and the resolver is a big one.

I could be convinced of that.  I don’t know where to draw the lines either, and in this particular situation, it’s dependent on arbitrary places in each deployment where the lines have been drawn before.

I think my first vote at this point would just be for a comment like the one in sshd_config in idp.properties along with an explicit note about which deployment scenarios can’t be used with the properties files unless you know what you’re doing(e.g. “if you have two directories, please go figure it out and come back here later").