As another way to debug, you could turn on a switch in the conf file and have per-message ID log files. I was thinking we would use a combination of the SMTP ID # that James creates, ThreadLocal, and some simple add-ons to the existing mailet context logging.
The logging cycle (per file/message) would go like this...
- mark that it was received via smtp (or maybe fetchpop?)
- starting this processor
- any log messages from matchers/mailets also get put in here
- report what mailets do fire (?), so you can see which matchers evaluate to true, and if a message keeps circulating.
- say it ended.
A note or two...
1. if you do MailetContext.sendMail, that gets a new #, and the original message log file should report that it sent something and created that new #. This should let you see.... 4.log has entry "sent message to create #5", see 5.log has entry "sent message to create #6", etc...
The only issue perhaps is what happens when some bloak leaves this on in a production environment... do we stop logging or do roll-overs after some point, or what?
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com/ p. 1.301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
