<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 4/15/14 11:46 AM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF72CBD9.B980%25cantor.2@osu.edu" type="cite">
<pre wrap="">On 4/15/14, 11:41 AM, "Tom Zeller" <a class="moz-txt-link-rfc2396E" href="mailto:tzeller@dragonacea.biz"><tzeller@dragonacea.biz></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
As you originally suggested, injecting the Event ID as a property of a
handler is fine with me.
</pre>
</blockquote>
<pre wrap="">
I can live with it (and it's certainly less work), but I suspect we'll run
into cases where handlers throw exceptions in cases that mean different
things to the overall flow. But I haven't looked (and certainly handlers
are meant to be discrete to the point of not doing this).
</pre>
</blockquote>
<br>
Yeah, for that reason I'm not particularly keen on the idea of
injecting things into the message handlers that are really about
profile handling logic. That seems like a bad
separation-of-concerns.<br>
<br>
Can't we get pretty much the same effect by injecting the event ID
into the adaptor? That also takes care more cleanly of the
contextual-specificity of the event ID, for example if sometimes an
exception from handler X means different things.<br>
<br>
There's obviously an issue if 1) the handler is actually a handler
chain (you don't know from which specific handler the exception
came) and 2) you actually need (in that particular adaptor instance)
to differentiate behavior based on different handlers in the chain.
Re: #2 I'd be interested to see cases where that was actually
true. Assuming they do exist: I think you could easily solve this
by dispensing with the actual handler chain and just having an
adaptor for a List<MessageHandler>. Then it knows which one
it's executing, and you can have a Map which maps Handler X ->
Event E. Or if we ever do make use of more strongly typed
exceptions in the handlers: (Handler X, Exception Y) -> Event E.
<br>
<br>
Or of course you could do something similar along with wrapping each
handler in its own distinct adaptor with an injected event ID.
Possibly even executed in a subflow.<br>
<br>
The MessageHandlerChain was/is a usable abstraction for the library,
but if it doesn't make sense in the context of WebFlow and
event-based handling, then we don't have to use it. It just loops of
the List<MessageHandler>, so there's not much to
re-implementing that in way more useful for WebFlow, etc.<br>
<br>
<br>
On a completely different note: I did have some very early plans
way, way back for how error handling would work in a pure
MessageDecoder/-Encoder and MessageHandler environment. That's the
interfaces in the messaging-api 'error' and 'error.servlet'
packages. (I may be the only one whose even aware of them). I did
have some impls in my proof-of-concept repo from years ago but none
of those made it into OpenSAML, since back then it wasn't clear
where we were going. Mostly of historical interest, and maybe not
relevant for use in SWF. But for example you can probably see where
I was going with the pipeline one that handles an error using an
outbound message encoder, to reply to the responder. There was also
an assumption of the use of a bit more structured exception handling
and exception types than we do today.<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>