Items for Friday

[Rod Widdowson]

Thanks All

I've heard enough to know that this was a wrong direction to go in.  I'll close 1115 as mistaken.  

But I've also heard enough to ask that Brent cast his eyes over the change I made in this space[1]  Given this discussion I can see
how to finish off the refactoring, but I'd like a +1 that this is going in a way Brent is comfortable with.

> I was thinking maybe we should just declare a public IdP class to hold any static Spring defaults (and we could make a public
constant
> from the builder and assign it into the IdP field).

That would certainly avoid me making an ignomious fool of myself again :-).

I'm struggling on how to do this.  Since I'm super aware of this constraint too:

>. it would be advisable to not repeat the actual default values for batch from the HCB if we can avoid it.

If we centralize the defaults (say in a class with each client deriving from it) we now have the have the knowledge in two places.
The parser needs to know that the default is different and the per client type class needs to have the value.

Best idea I can come up with is to have the class with the defaults injected into the builder as well:
 - If a value has been set we use it, otherwise
 - If a default bean was injected we use that
 - Otherwise we use the default default.

I think that that is also backwards compatible.

[1] http://svn.shibboleth.net/view/java-identity-provider?view=revision&revision=8607


I could give that a bash if people wanted.

Rod