MessageHandlers and SOAP faults

[Cantor, Scott]

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

>Hmm. Still not clear.  The input comes from a MessageDecoder, right?  That's generic-ed.  A MessageDecoder<SAMLObject> will produce a SAMLObject.   If somehow what got sent on the wire is not, the throwing would be there.  I just checked and the decoders are
> unconditionally casting, should probably fix that to check and gracefully throw MessageDecodingException.  But either way that's where I've envisioned the enforcement of the type that goes into the pipeline.
>
>As you said, the output type is determined by the code, so no real problem there.

I would have to go back into the code and dig out why this didn't work, but I know that it didn't. There were places where actions were typed to be receiving a SAMLObject that didn't in fact always receive a SAMLObject and that broke. Some of them were probably in the non-SAML parts of the system.

It's possible it was less about SAMLObject and more about a specific type of object, AuthnRequest or Response perhaps, and the actions were no longer exclusive to that message type. I really don't remember, I just remember that it all failed to hang together and I know I sent some notes about it at the time. Things either started not compiling, or were opening up the chance of cast exceptions.

If you recall, we determined through testing that if the runtime behavior violates the assumption of the generic class, you just get a class cast exception. Just claiming that a type is Foo when the type isn't always Foo is just an implicit cast to Foo at the top of the method. And that was what the actions were doing essentially, in places where it wasn't always going to be a Foo.

Perhaps my error was in not just picking a different generic type parameter instead of removing the generic, but I don't think in actual fact that it's possibly an error to ever inherit out the generic, because all that does is eliminate a type that's going to get erased at runtime anyway. I'm basically making the inheriting code non-generic which just means the types aren't implicit to the compiler.

If you're worried that we're injecting something that is type-locked into something I removed the generic from, the only way that could fail at runtime is with an implicit cast that would have happened anyway because if the object it's handed is the wrong type, that was going to fail at runtime one place or the other. All we're possibly doing is moving around a cast exception from one class to another. I don't think it can introduce a failure mode that wasn't already going to fail.

-- Scott