Noel, I'm sending here attached a possible patch to LinearProcessor v2 that would do what I'm talking about. It has not been tested, it's just as a basis of discussion, and as a way for me to get deeper in my understanding of the James code. If all this discussion dies, no problem: it has been a good experiment.
It would handle the following init parameter syntax:
<onMatchException>match|nomatch|error|aProcessorName</onMatchException>
<onMailetException>ignore|error|aProcessorName</onMailetException>
the default being "error".
There is also a little change to JamesSpoolManager: it is a partially redundant
mail.setState(Mail.ERROR) that I moved to another place. Partially redundant in the
current code because if it gets there it is either because the requested processor was
not found or because processor.service(mail) returned an exception, and in that case
the state was already set to Mail.ERROR by handleException.
Instead with the changes to LinearProcessor the next state must be set before throwing
the exception.
A possible problem is that an exception could occur after the mail object has been
modified in place, and no "rollback" is done. But this problem occurs also in the
current code to mails sent to the error processor.
Does it make any sense at all?
Vincenzo
onException_v2.patch
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
