Well, I'd like to say I understood that, but I'm not sure I did.

So given an e-mail addressed to [EMAIL PROTECTED] and [EMAIL PROTECTED], I want my
Matcher-or-Mailet to make sure it gets (locally) delivered to [EMAIL PROTECTED] and
[EMAIL PROTECTED] instead.  I get the impression I should be using the "All" matcher
from another responder to this thread.

If that's the case, thenw hat should my Matcher do?

1. Modify the recipients to replace [EMAIL PROTECTED] with [EMAIL PROTECTED] ?
2. MailetContext.send() the Mail to [EMAIL PROTECTED]
3. Something else?

I hate to say it, but I think I need a flow chart and Venn diagrams to
understand this.

Regards,
Brian.

-----Original Message-----
From: Noel J. Bergman [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 16, 2003 1:31 PM
To: James Users List
Subject: RE: What to do with my new matcher?


> When I read the Javadoc for Matcher when planning to do 
> WildcardAddress,
it
> said that the Mailet container has the awesome capability to fork 
> messages for you and all you have to do is return the recipients you 
> wish to
receive
> that message.  So I bent the rules a little bit and made it return the 
> entire recipient list, but with the recipients who were wildcarding 
> their MailAddress replaced with their normal MailAddress.

HOWEVER ...

When the processor "forks", it looks at the Collection returned by the
Matcher *AND* the Collection attached to the Mail instance.  It removes the
latter from the former, sends the former to the Mailet, and lets the
remainder from the latter continue through the pipeline.

After your <mailet> tag, there is a message still in the pipeline containing
all of the original addresses that were not in the Collection returned by
your matcher, e.g., those that you've just matched, unless you've also "bent
the rules" further in a very implementation specific way, and changed the
attached Recipient collection.

Changing the Mail instance's recipient list is not defined in the Mailet
API.  Making it a defined/allowed operation for Matchers in future revisions
of the Mailet API would require change (and performance degradation) in the
processor.

        --- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to