Message handlers and error handling

[Cantor, Scott]

On 4/16/14, 2:33 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>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.

Other than the the chain issue, yeah, good point.

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

Well, I think it comes up in the standard case, the inbound chain for
security policy. Some are about authentication, and some are about replay
and freshness. Pretty different cases.

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

I guess, it just starts to get a little unwieldy. I'd just adapt each
handler directly, but that doesn't work well with the code as is, since
it's running those handlers as a set returned by the ProfileConfiguration.

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

Right, then it really devolves into what Tom said, just use a subflow and
forget the chain. The profile config would be changed to return subflow
IDs for the inbound and outbound handlers to run (and of course they're no
longer limited to handlers, which maybe is a good idea in its own right
anyway).

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

They don't ring a bell, I can look at it.

-- Scott