Noel, I tested the experimental patch sent yesterday, and it works fine.
I think that it can be useful, and it simply has no effect if the configuration entries are not used. If it is accepted and added to James, I would modify the AttachmentFileNameIs and HasAttachment patches that I submitted in the last two days, leaving out the global catches. I would also prepare the patches to v3 and resubmit. Any thoughts? Vincenzo > -----Original Message----- > From: Vincenzo Gianferrari Pini > [mailto:[EMAIL PROTECTED] > Sent: luned� 9 giugno 2003 18.46 > To: James Developers List > Subject: [no virus] RE: Separating internal errors from addressing > errors in config.xml > > > Oops, a small mistake. Better this one. > > Vincenzo > > > -----Original Message----- > > From: Vincenzo Gianferrari Pini > > [mailto:[EMAIL PROTECTED] > > Sent: luned� 9 giugno 2003 18.31 > > To: James Developers List > > Subject: [no virus] RE: Separating internal errors from addressing > > errors in config.xml > > > > > > 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 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
