Spring shorthand, again

[Nate Klingenstein]

> I don't think it works well, basically. LDAP simply doesn't have the requisite notion of DataSource to make it simple to share it across cases, and authentication is very different from data lookup with a service account.

I would have to get the dry heaves out of my system afterwards, but I could get argued into a different abstraction layer that looks a lot like the data connector elements do.  I’m not sure that solves much, but you guys are much more familiar with that granularity than I am.

From where I sit, this sort of data source aggregation was basically what LDAP and JNDI and blah were for, and I’m looking at where each of those is sitting in the history file.

There are already enough sites that conflate “Active Directory as implementation”, “LDAP as protocol”, and “every other user data store that also speaks LDAP as a protocol” that I would have a very hard time arguing that LDAP as a common representation is helping.

That says nothing about its use as a protocol or the use of the library, which absolutely need to remain, of course, but you’ve already earned the “I told you so” on the “always blame LDAP” comment.

> I doubt a URL would help much, people can't click that in an editor usually. The note just has to be really brief.

That would be fine.  I’d volunteer these as two statements to start chiseling from.

# These property files are only for basic deployment.  If you’re not sure whether your
# deployment is basic, please read the documentation.
# <maybe a url>

# Commented out properties in the distribution always default to the shown value.
# To override a property, you must set it explicitly.