MessageHandlers and SOAP faults

Cantor, Scott cantor.2 at osu.edu
Thu Jun 11 23:46:55 EDT 2015


On 6/11/15, 11:10 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:

>It could certainly.  I was focused on the fact that the Event mapping isn't very rich in detail.  All you basically get to do is map an Event to a QName code.  That may or may not be enough.

Well, maybe, but if it's not exposed to the deployer, then it's not configurable either. I didn't want fault codes to depend on our code, but on a mapping table. SOAP faults aren't terribly interesting anyway, but it made more difference for SAML statuses.

>But that is close to what I had in mind:  1) the emitter sets the Fault in the context tree somewhere 2) it then throws 3) (IIUC) something up above in SWF is catching that exception, and mapping it to an action to run (e.g. AddSOAPFault) 4) that action, as one possible strategy, can pull the previously-set fault out and use it directly.

The question is how it knows what Fault to put into the context tree.

>If by that, you mean having SWF catch thrown Exceptions in the appropriate places and transitioning to the AddSOAPFault action, I agree.

No, I specifically meant mapping an event to a fault rather than hardcoding it. I tried to avoid that.

>I guess I'm not clear how that could happen. If everything were generic-ed, I don't think you could.

If it's left untyped (meaning the actions themselves stay generic and not typed), I'm not sure what it buys (and I'm not sure that's any different from declaring them without type parameters at all, since either way the type's gone at runtime).

>Which I think can only happen if you have non-generic code operating on the generic types.  Which I guess I'm saying I didn't think we'd have.  I'm sure the big picture is complicated though.

We had code that wasn't SAML specific operating on SAMLObject originally. We also had code that originally assumed Response outbound and needed to handle other kinds of messages, same on the input side. Basically almost anywhere the type was assumed, it tended to be a bad assumption.

Something had to change, I just probably went too far with it because it was in my way and wasn't really helping me do anything.

-- Scott



More information about the dev mailing list