Function use in the IdP

Brent Putman putmanb at georgetown.edu
Wed Nov 12 13:56:15 EST 2014


On 11/12/14 1:45 PM, Brent Putman wrote:
>
>
>
> I imagine it may be too late to change every place where we
> instantiate a PRC to use a (new) 2-arg constructor - and that's
> assuming the message context instances are even available at that
> point.  But you guys are more familiar.  If it's just changing a few
> places, etc, then maybe worth doing. 

Actually, just realized, the MC are not necessarily typically available,
I think, in our current model.  The inbound is generated by the Decoder
usually, after the PRC is ctor-ed.  My memory is hazy... I think this is
accounted for by a difference in processing models.  I think I
originally designed: 1) decode, so get an inbound MC 2) create your
InOutOperationContext  with that (and a new outbound MC), as context for
the middle "business logic" processing 3) run "business logic"  4)
encode outbound.

So I think the actual design with the PRC (which Chad added in the IdP,
and was later moved to OpenSAML) diverged there. Now there's an
impedance mismatch (I think) - we assume you create a PRC upfront, and
then hang stuff off of it as you go.

Have to think more - maybe there's a way to solve - like just overriding
and making the setParent(BaseContext) public on MessageContext.  Then
wherever we set the MC's on the PRC, just also set the parent explicitly. 

Unless this isn't a big deal, in which case we can just leave as-is for now.

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


More information about the dev mailing list