StoredID Canonicalization, DataSources, configuration & code structure

[Cantor, Scott]

On 1/30/14, 10:33 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>> 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.

Oh, that's fine.

>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.

Sure.

>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'll review, I really don't remember what the dependencies are. Ideally I
guess it would be better if any SAML-specific portions were in saml-*, but
maybe this is related to the attribute mapping stuff?

>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

If any of this has to cross two impl modules. But I also don't see any
reason why we couldn't move SAML-specific resolver plugins into saml-impl
either. I like verifying that our package layout is correct by forcing
some of our own plugins to live in two modules.

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

I don't know enough of the code to say, but it sounds correct to me.

-- Scott