StoredID Canonicalization, DataSources, configuration & code structure

[Rod Widdowson]

> I think this is fine as long as we're not removing the option to declare
> them locally within the resolver as we do now. It doesn't even break the
> resolver itself reloading, right? 

Absolutely not.  It a reladed resolver would just pick up the existing bean
for the DataSource from the parent Spring context.

> If the data connection is outside that
> context, it doesn't get flushed by a reload, which is fine for most cases.

Exactly.  Good.

> I more or less expected that (but I wasn't sure if the resolver-impl
> module actually depended on the saml module. Does it actually depend on
> saml-impl? We probably don't want that...

If it does (and I think it does) it is *only* for the testing scope. 

But that is enough to mean that all testing now has to follow this
dependency.  This is why when I add a C14N action to saml-impl I add a test
to attribute-impl - to test the round trip from
AttributeDefinition->Encoder->NameID->Decoder->Principal. 

Of course idp-attribute-resolver-spring depends on both
attribute-resolver-impl and saml-impl, and for completeness I'll note that
attribute-resolver-api depends on saml-api.

> I think it belongs in saml-api if it's an actual API. Persistent IDs are
> for all intents and purposes SAML-specific, and if they ever become more,
> we can refactor then.

Does that mean you think that all three classes/interfaces should go into
-api.  That is to say:

PersistentIdEntry - what gets stored
PersistentIdStore - interface for where it gets stored
StoredIdStore - implementation of PersistentIdStore using a
java.sql.DataSource

>From what you say it feels like the first two go into -api and the third
into -impl.

Rod