Schema support for Spring <beans> in LDAP/RDBMS config

[Cantor, Scott]

On 2/11/14, 4:06 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>Daniel wrote the DataConnector parsers and is the expert here, so I'd wait
>for his definitive response.

It turns out the only schema conflict with having only <beans> in the LDAP
case is ldapUrl, so it's not a lot of attributes. But there's still the
mix/match issue I'm concerned about.

>We have already talked about the need for a new type of DataConnector
>which
>is purely a reference to a one defined in a different file (we needed this
>for the StoredID C14N as well as database pooling).

Well...data *source*, yes. Not data connector. I think it's a bigger deal
to start splitting the files up this way, but I guess we could. I would
personally find it a bit annoying.

>All the services
>support multiple input resources and so splitting Spring/Shibboleth schema
>over two files isn¹t a big deal, further the writing of the element into a
>ByteOutputStream just so that it can be parsed back again worries me in
>some
>undefinable manner.  Maybe this discussion has defined it.

I think we can handle that problem by just walking the tree and pulling in
the schemaLocation attribute to add onto the node before we serialize it.
I didn't do it just because I was focused on making validation work, but I
was going to try that today. I think it's actually pretty elegant,
overhead aside (and it's just one-time overhead).

>The Service infrastructure allows this (see attribute-params-config.xml)
>at
>no cost and there is something appealing about separating the two
>languages.

I'm open to it, but I think that amounts to just doing what we're doing
now and making <beans> and all or nothing choice, which was where I was
headed anyway.

>I will note that Daniel is in the middle of a large refactor of this stuff
>to deal with IDP-357 and IDP-354 so more changes here right now might be
>'contra-indicated'.

Alright, I'm not changing the schema right now, just noting we have to
decide.

I would add that my hopes to improve the schema for these plugins and
eliminate some of the constraints on child element order is a no-go. The
sequence is too embedded now and spread across a base type, plus there are
a mix of required, optional, and multiply occurring elements. Making it a
bag schema pretty much requires that the children be the same cardinality.
I might be able to tweak some of them, but not the LDAP or RDBMS ones.

-- Scott