Because of the change to use a dedicated matcher and mailet for end-of-processor handling, instead of using "All" and "Null" as in prior versions of James, we can take advantage of the fact that the matcher and mailet are inner classes of the LinearProcessor they service. I have added the following to the mailet:
public void service(Mail mail) {
mail.setState(Mail.GHOST);
+ StringBuffer warnBuffer = new StringBuffer(256)
+ .append("Message ")
+ .append(((MailImpl)mail).getName())
+ .append(" reached the end of this
processor, and is automatically deleted. This may indicate a configuration
error.");
+ LinearProcessor.this.getLogger().warn(warnBuffer.toString());
}
The change takes advantage of the nature of an inner class to use the linear
processor's logger, so that the message can be logged at the appropriate
logging level with the linear processor's other log messages. Because this
mailet is tightly coupled with James, rather than a generic mailet, there is
no reason not to cast from Mail to MailImpl, allowing access to the message
name.
This doesn't change the behavior, e.g., to support a dead letter drop, but
it does warn the James administrator, who would otherwise need to have DEBUG
turned on for the spool manager to see that the terminating matcher/mailet
had checked and serviced the e-mail.
--- Noel
[Committers: this code compiles, looks right, but is not tested. Please
test before committing]
-----Original Message-----
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 29, 2002 12:14
To: James Developers List
Subject: RE: terminating mailet
Danny,
I understand that you are upset at losing e-mail, but I believe that your
diagnosis is wrong.
Prior to JamesSpoolManager.java v1.11, that class included the following:
- //Add a Null mailet with All matcher to the processor
- // this is so if a message gets to the end of a processor,
- // it will always be ghosted
- Matcher matcher = matchLoader.getMatcher("All", mailetcontext);
- Mailet mailet = mailetLoader.getMailet("Null", mailetcontext, null);
- processor.add(matcher, mailet);
as you can see from the CVS. The "Terminating Mailet" is exactly the same
behavior, except that it provides unique names ("Terminating%Matcher%Name"
instead of "All" and "Terminating%Mailet%Name" instead of "Null"), so that
it becomes painfully obvious as to the nature of the problem. The
responsibility for adding those to the processor was moved from
JamesSpoolManager to LinearProcessor.
Regardless of the change, all e-mail reaching the end of a processor would
have been ghosted. Because of the change, the nature of the problem is made
plain. I don't know why you believe that e-mail reaching the end of a
processor "fell through", or to where it would have fallen.
Are you proposing that a new message store be added for e-mail reaching the
end of a processor, rather than ghosting them as has always been done?
--- Noel
-----Original Message-----
From: Danny Angus [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 29, 2002 3:34
To: James Developers List
Subject: terminating mailet
I've just lost 8hrs of mail thanks to the "terminating mailet"
I remember some discussions baout this, I now have an opinion.. which is
that the terminating mailet is a royal pain in the arse, it should either
set the state to something like "dead-letter" or it should be omited and
allow mail to fall through like it used to.
IMHO deleting mail just because it hasn't been handled correctly is overly
harsh punishment for poor configuration.
d.
james-diffs
Description: Binary data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
