Basically, matchers and mailets ought to do the best that they can. If they
can handle an exception, they should. If the exception can't be reasonably
handled, the current expectation is for the mailet to set the state to
ERROR, and to indicate why. Right now that latter isn't happening except
when LinearProcessor catches an MessagingException thrown from a matcher or
mailet.
You seem to be proposing that the matcher or mailet could throw it back to
the processor. I don't have a problem with the idea of adding an attribute
to the processor level to control what to do if a matcher or mailet throws
an exception. But we should think it through first. I've also thought to
add a class attribute, so that we can have custom processor types.
You've identified several options:
- matchException=match
- matchException=nomatch
- [mailet|match]Exception=<processor>
The default would be the "error" processor. On the surface, it seems
reasonable, but there are issues to consider. For example, if I were to
have:
<processor mailetException="specialErrorProcessor">
<mailet match="All" class="ToProcessor">
<processor> error </processor>
</mailet
</processor>
what do you propose should be done? The case I provided is an explicit
case, but there are also implicit cases.
Another issue to consider: what about where there is an exception effecting
a single recipient, or individual sets of recipients? Do we require
Matchers and Mailets to build and throw a chain of MessagingException
objects? Do we need an exception class similar to SendFailedException, with
collections of which ones failed and which ones succeeded? Is there another
way?
For example, Serge pointed out that although it isn't supported, the intent
of the Matcher was to be able to return a collection of collections.
Perhaps Serge could discuss that again, and we could consider how that might
be used to address exceptions.
Please note that for James v2, we don't want to do anything that breaks any
third party code. For James v3, we would like not to, but could if
necessary, and by using the class attribute of the processor element, we
could have a processor compatible with James v2 matchers/mailets if the
interface conventions changed.
I'm not saying that we should preserve the status quo, but am pointing out
some of the issues that need to be addressed.
Above all else, we need to keep in mind that the paramount obligation of a
mail server is reliable delivery. It can try to filter, etc., but it should
always operate in such fashion as to ensure that mail is not lost.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
