Brian, Your matcher *is* modifying the Mail, as it is changing the recipients list.
It may just be a matter of personal taste, but IMHO the reason of the convention that "a matcher should never modify a Mail object" is that a configuration file becomes harder to read if there are side effects in the matcher. The meaning of <mailet match="aMatcher=aCondition" class="aMailet"> is "for every recipient (even all) matching the 'aMatcher=aCondition' check do fork a copy of the message to be processed by 'aMailet'": the *only* action of the matcher is to fork. In your case what are you using as a target mailet? I guess you are doing some kind of "no operation". Instead of changing the recipients list in your matcher, you can match all and change such list using MailImpl.setRecipients(Collection) in a mailet, whose purpose is to do exactly such job, and moreover you would have any mailet parameter available to customize the behaviour. This approach though could open the following debate: "what will happen in V3 for user mailets, as, unlike getRecipients(), setRecipients(Collection) is not defined in the Mail interface but only in the MailImpl implementor?" Shouldn't we add it to the Mail interface? More generally, as things stand, I'm convinced that a large number of user written matchers and mailets *will not* work under V3 unless they are heavily rewritten, or unless the interface is made richer. IMHO this, together with the current lack of sync in CVS between branch_2_1_fcs and head, may kill V3. Vincenzo > -----Original Message----- > From: Brian J. Sayatovic [mailto:[EMAIL PROTECTED] > Sent: mercoledi 15 ottobre 2003 23.47 > To: 'James Users List' > Subject: RE: What to do with my new matcher? > > > It doesn't modify the Mail. It leaves it in tact, but the > Matcher API says > the Matcher can return the set of recipients that match. So in my case, I > look at the Mail's recipients, and build an independent list of recipients > to return. > > I build the independent list by either 'filtering' an address with a user > that matches the pattern and creating an address with the proper > user, or if > it doesn't match, using the address as it was. It does this for each > recipient in the Mail. > > I've configured James to use this as a replacement for the All/ToProcessor > for the spool processor. Any e-mail that comes in is 'matched' and the > recipieint list contains all of the recipients the original Mail had. The > actual Mail headers still contain the original To recipients. > > I originally considered using a Mailet, but in my last Mailet 'forking' a > messages seemed quite a pain. When I re-read the description of what a > Matcher is for this time around, it seemed like the perfect fit: (From the > JavaDoc) > > An important feature of the mailet container is the ability > to fork processing of messages. When a message first arrives > at the server, it might have multiple recipients specified. > As a message is passed to a matcher, the matcher might only > "match" one of the listed recipients. It would then return > only the matching recipient in the Collection. The mailet > container should then duplicate the message splitting the > recipient list across the two messages as per what the > matcher returned. > > If I've gone down the wrong path, I'll gladly backup and go down the right > one. I'd really like to know because I plans tonight to pair my other > custom Mailet (spam filter) with a Matcher to handle the "forking" part > instead of the code I'm using now. > > Regards, > Brian. > > -----Original Message----- > From: Vincenzo Gianferrari Pini [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 7:19 AM To: James Users List Subject: RE: What to do with my new matcher? > Well, I didn't know about that one. I just checked > http://james.apache.org/provided_matchers_2_1.html and didn't see that > one listed. Is this new for the next version of James? > It has been added in v2.2.0a3. > Anyways, I'll take a guess that RecipientIsRegex will return only > those recipients which match a certain regular expression. The > WildcardAddressMatcher not only uses a regular expression for > matching, but will replace the 'user' portion of a MailAddress with > the first RegEx matchign group. This allows me to have > '[EMAIL PROTECTED]' > be delivered to '[EMAIL PROTECTED]' when I give it the RegEx in the > condition of '([^-]+)-' (which is applied to the user portion of the > MailAddress). Very good. But a mailet would be more appropriate, as per convention a matcher should never modify a Mail object. Bye, Vincenzo --------------------------------------------------------------------- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
