<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 6/11/15 9:24 PM, Cantor, Scott
wrote:</div>
<blockquote cite="mid:12669BFB-0F8B-45A4-8688-714C94527F78@osu.edu"
type="cite">
<pre wrap="">
I guess my take is that if it's ultimately a profile flow running your handler here, just have the MessageHandler throw an exception that will get mapped to an Event in the surrounding profile flow and then AddSOAPFault could be used in the "outer" flow that's actually invoking the handler. That's basically how the ECP stuff works I think.</pre>
</blockquote>
<br>
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. <br>
<br>
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.<br>
<br>
<blockquote cite="mid:12669BFB-0F8B-45A4-8688-714C94527F78@osu.edu"
type="cite"><br>
<pre wrap="">
Isn't the problem that you don't have a ProfileRequestContext at all? </pre>
</blockquote>
In MessageHandler, right, no PRC. <br>
<br>
<blockquote cite="mid:12669BFB-0F8B-45A4-8688-714C94527F78@osu.edu"
type="cite">
<pre wrap="">If you have one, you can just move the FaultCodeMappingFunction out of the MessageHandler </pre>
</blockquote>
<br>
Oh, no, it wouldn't be in the MessageHandler. I'm talking strictly
about what the AddSOAPFault action does. Adding another strategy
there.<br>
<br>
<blockquote cite="mid:12669BFB-0F8B-45A4-8688-714C94527F78@osu.edu"
type="cite">
<pre wrap="">into some place that's not "disallowed" from knowing about the EventContext and inject it with Spring when the time comes. The default function could be something more neutral.</pre>
</blockquote>
<br>
The MessageHandler does have the MessageContext which is part of the
PRC. So the proposed strategy function injected to AddSOAPFault
could pull it out of the inbound PRC MessageContext.<br>
<br>
I'm just proposing an additional strategy to pull a Fault directly
out of the PRC, in addition tho the current one that pulls the Event
out and maps to QName.<br>
<br>
<blockquote cite="mid:12669BFB-0F8B-45A4-8688-714C94527F78@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">The way I did it in the delegation extension was to have the fault-emitting code store an actual Fault object in a message subcontext, and then something later pulls it out. Can you see any reason not to augment the AddSOAPFault action with an additional Function<ProfileRequestContext,Fault>,
which if non-null and it produces anything, bypasses the rest? Or is there a better way?
</pre>
</blockquote>
<pre wrap="">
That sounds fine too, or just create a different action that suits your needs. But more to the point, I wouldn't really want to not be reusing the same fault-mapping logic in the IdP that's already there.</pre>
</blockquote>
<br>
If by that, you mean having SWF catch thrown Exceptions in the
appropriate places and transitioning to the AddSOAPFault action, I
agree.<br>
<br>
<br>
<br>
<br>
<blockquote cite="mid:12669BFB-0F8B-45A4-8688-714C94527F78@osu.edu"
type="cite">
The actual use of generics in the PRC is basically unworkable
because in any given case, you may get an invalid message in there
</blockquote>
<br>
I guess I'm not clear how that could happen. If everything were
generic-ed, I don't think you could. <br>
<br>
<blockquote cite="mid:12669BFB-0F8B-45A4-8688-714C94527F78@osu.edu"
type="cite"><br>
<blockquote type="cite">
<pre wrap="">Wondering whether all our actions are like that.
</pre>
</blockquote>
<pre wrap="">
They are, because a lot of stuff crashes if it's actually nailed down. Basically if the generic type is made non-generic, that introduces assumptions that the actual code does not need to impose.</pre>
</blockquote>
<br>
I'll think about it more, but hmmm. Not what I expected.<br>
<br>
<br>
<blockquote cite="mid:12669BFB-0F8B-45A4-8688-714C94527F78@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap=""> Anyway, with careful wiring it doesn't actually break I guess, it's just perhaps unsettling...
</pre>
</blockquote>
<pre wrap="">
I considered at one point just removing the generics entirely because it just doesn't work to use it in many places without turning controllable error checking into runtime exceptions needlessly.
Basically, when you're using generics to avoid casts, you'd better be damn sure that the objects can't ever be anything else,</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<br>
<blockquote cite="mid:12669BFB-0F8B-45A4-8688-714C94527F78@osu.edu"
type="cite">
<pre wrap=""> and these flows are never really sure of that because that's just what getting bad input means.
</pre>
</blockquote>
<br>
I'm not seeing how the input would be bad, if everything were
properly generic-ed. If not, then yes.<br>
<br>
</body>
</html>