MessageHandlers and SOAP faults

[Cantor, Scott]

On 6/12/15, 5:59 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
>
>In short, it seems to me that the SOAP processing component is the thing that ought to build the Fault, since
>that's where all the info is.

I guess I buy that, though I would note that there's still a need to make sure we can switch on and off detailed errors (which are off by default).

>Sure, but the win with generics is compile-time type checking.  As long as you *don't* have non-generic-ed code putting things into or pulling things out of generically typed structures (so as Objects, what they are at runtime), then it's guaranteed that you can not have a ClassCastException.  If that assumption is being violated, then there's a problem.  And that's kind of what I'm noting here.  In the SOAP fault action, the PRC isn't genericed, so it's (illegally) allowed to put a MessageContext<Fault> into the PRC.  As if the type is fungible, when it really shouldn't be.

Well, looking at that specific example, this is probably one reason I was very uncomfortable with the whole thing. In a scenario with SOAP, you might have a lot of actions that are assuming they're operating on an Envelope as the outbound message type. But in the fault action, it has to be able to set a Fault as the outbound type. I'm not sure you can hang together a system that suddenly changes the generic types in the PRC from one to the other without it being very suspicious looking, even though at runtime it obviously doesn't even care.

Maybe it "works" but I just didn't feel like it made sense to me and got concerned that it wouldn't work.

There's probably a similar example with ECP because I think it actually puts the Response into the outbound slot because it can have the encoder create the Envelope, but when an exception occurs, it will sometimes have to end up sending out a Fault.

That all seemed very weird to me.

>I'm not convinced that this couldn't be made to work.  But I don't necessarily want to rathole on this right now.  If we were going to change anything here, it likely would be a Future timescale thing.

I think for it to work, a lot of code had to be changed to fix up the assumptions and at the time I didn't know how to do that or want to take the time, so avoiding generics when I knew I wasn't doing anything "wrong" was the simpler choice.

If I'm casting something, or if I have left a generic type in, I know I'm doing it and I'm always checking if it's right. If there are bugs in that respect, they're not going to be common. I am always extremely paranoid in Java about nulls and casts.

-- Scott