<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/12/15 7:13 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:2EFD99EF-0BF2-4427-9190-F35A52AFA1B8@osu.edu"
type="cite">
<pre wrap="">
</pre>
<pre wrap="">
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).</pre>
</blockquote>
<br>
I wouldn't have thought that was important in the proposed scenario
where the whole Fault is supplied. What's the reason or use case
for *not* wanting to send the FaultString (much less the Detail) if
that's what the Fault emitter wanted? I guess AddSOAPFault could
remove the FaultString if detailedErrors=false, but I'm not seeing
why it should.<br>
<br>
<br>
<blockquote cite="mid:2EFD99EF-0BF2-4427-9190-F35A52AFA1B8@osu.edu"
type="cite">
<pre wrap="">
</pre>
<pre wrap="">
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. </pre>
</blockquote>
<br>
Well, actually, not really. They should really never do that, same
for the MessageHandlers. In handlers and actions, the SOAP Envelope
should always be accessed through (for SOAP 1.1) the SOAP11Context.
That works regardless of whether you're doing "payload oriented"
messaging (where the message is SAMLObject or whatever) or
"transport-oriented" (where the message is Envelope). The main
purpose of that context is to abstract away the difference. <br>
<br>
I mean, you *could* have a set of Actions, MessageHandlers and
MessageEncoders that strictly assume transport messaging and that
the message is Envelope. But those would be of limited usefulness.
It's better to make them work with both styles, IMHO.<br>
<br>
<br>
<blockquote cite="mid:2EFD99EF-0BF2-4427-9190-F35A52AFA1B8@osu.edu"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
Yes, that is actually the other problem I see with the AddSOAPFault
approach, hence my initial comments about the generics. The way I
always envisioned SOAP fault handling to work (or any error handling
pipeline where the error message type wasn't the same as the
"regular" message type) was via a dedicated outbound pipeline. That
was the point behind the stuff I put into messaging-api, package
org.opensaml.messaging.error.<br>
<br>
If your main flow is modeled as e.g.
ProfileRequestContext<SAMLObject,SAMLObject>, then obviously
you can't put a Fault as the outbound message. There must therefore
be another mechanism for branching to an outbound error pipeline. <br>
<br>
<br>
<blockquote cite="mid:2EFD99EF-0BF2-4427-9190-F35A52AFA1B8@osu.edu"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<br>
Yeah, I had already thought about this general issue. That's the
org.opensaml.messaging.error stuff. I haven't looked at the ECP
stuff, but was going to.<br>
<br>
Fwiw, there is a similar issue I had to deal with in the SOAP client
on receiving back a Fault response. Actually the issue is really in
the HttpClient HttpResponse MessageDecoder impl. You can't just
return the Fault in the MessageContext as the getMessage() for
exactly these same reasons. So you don't. The decoder throws a
MessageDecodingException specialization that carries the fault,
which is then caught by the client and re-thrown as a
SOAPFaultException.<br>
<br>
<br>
</body>
</html>