Wiring PopulateSignatureSigningParameters ?

[Brent Putman]

On 4/3/14 2:36 PM, Cantor, Scott wrote:
>
> But I actually mispoke in my last suggestion, we can't actually wire in a
> SecurityConfiguration with the key because we need the resolver to work
> for that, which is why the auto-wired code now is poking in a Parameters
> object directly.
>
> But once you have the resolver working we can make a little more progress.

I haven't looked at any of this, but couldn't you just wire in a
Static*Resolver for now and change it when I have the Basic- one
working?  Of course you'd have to summon up the signing credential, etc,
to inject in to the static resolver, so that would obviously have to be
faked up.  But you could a least move "more forward" that way. 

I guess it's just a question of which bits you go back in and change later.


>
> I did want to note that Rod's going to need classes to build the
> *Configuration objects to serve to the rest of the IdP, and right now you
> have some Basic*Confguration beans in the xmlsec-impl module. We might
> want to move those into -api or we'll just end up duplicating them.

Yeah, frack.  I was thinking/hoping that those would all just be beans
wired from plain Spring beans files, etc, and the IdP wouldn't have to
actually know about them.  Or maybe they'd be in -spring modules, where
I thought we relaxed the no-depending-on-impls policy.  But if that's
not true... yeah.    I'm wondering whether there are other bits like
this where the -impl dependency policy is waiting to bite us.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140403/25b82f53/attachment-0001.html