MessageHandlers and SOAP faults

[Brent Putman]

On 6/11/15 11:41 PM, Cantor, Scott wrote:
> 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:
>
> 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.


If so, then they probably shouldn't have had a specific generic type. 
It would be ok for an Action, etc, to have generic parameters, meaning
not actually specify the type, if they do not care about or operate on
the inbound/outbound message types.  The don't have to declare specific
types.  The calling/instantiating code would do that.  I wonder if that
was the fundamental issue here...

>
> 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.

As I mentioned, the way generics work, if you do not have non-generic
aware code treating the components non-generically, then you literally
can not have a ClassCastException.

E.g. If something declares a Set<String> and passes that into something
else which is *not* generically-aware and it treats it as just a Set
and stores arbitrary Objects in it, then you have a problem.  The
solution is to not have the non-generically-aware component in the
first place.

This was an issue in the early days of generics where you had lots of
non-generic code, esp for collection types and such.  But shouldn't be
an issue for our own code, since we control it...

>
> 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.

Right, v2 did that and it was wrong.  The solution is to not have
generic types being treated by other things non-generically. Everything
has to be genericed.  If it is, cast exceptions literally can not
happen. It's guaranteed by the compiler.  Or so my generics book tells me.

>
> 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.

I don't quite grok that, but perhaps it's what I said above.  There's a
difference between: 1) having generic parameters on a class 2) actually
nailing down the generics right in the class definition.  You don't
always want or need to do the latter.  Not nailing down allows the
class to be used in the widest possible way.

>
> If you're worried that we're injecting something that is type-locked into something I removed the generic from,


I *think* I'm actually concerned more about the opposite case, but not
sure.

>  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.


Head spinning, can't go on, need more oxygen... 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150612/9f7db9b1/attachment-0001.html>